Refactoring and file architecture, take 1

[plocket]

Right now I'm seeing at least two things that can probably be easily broken out:

• names.js [or text_manipulation.js] to handle incrementing names and getting various types of file names
• [This one has its own issue already - Refactor: Make file handling its own object/class, separate from scope #478] file_handler.js/file_existance.js to handle saving, downloading, and uploading of files. It's actually a somewhat tricky problem and there's state involved because of asynchronous operations, like checking when a file is done downloading.

This is a long term issue. There are a lot more things that need to be worked out that aren't in issues yet. We will make other issues out of the items in here when an item is decided on. When all items have been addressed and this peters out for a bit, we'll close it.

More things:

• path names? Separate from file handling or in the same place? Should it be a class or an object of functions? What should its name be? Paths, ALKilnPaths?
• time.js's name needs to change to something like wait.js or sleep.js or async.js.
• reports
• string manipulation in general?

[BryceStevenWilley]

My only major opinions here are:

• the fewer files the better. In file searching is usually easier than whole-project searching, and it's easier to choose and glance through 3 files than it is 6.
• Names don't need to have ALKiln in them. From what I know about CommonJS requires, you usually need to pass a full path, so there's no worry about ALKiln/lib/paths.js getting mixed up with someone else's path.js.

[BryceStevenWilley]

I don't have opinions here much, but I am realizing that there's some confusing new with how scope.js is setup with an object of functions. Specifically the fact that you directly pass the scope object into each function as a parameter, but it's also the object of the function itself. I know that JS has a lot of obscure rules about this, and I agree we should avoid running into bugs like that anyway, but IMO we should separate out running state vs functions vs constants into their own things.

[plocket]

As an aide to that, we might make an issue to mark which functions don't use scope in them at all and plan to separate those somehow. I do prefer to avoid this where possible. The whole use of scope is a bit weird and started from a bit of a misunderstanding. We could possibly try to refactor it into just being a state object. I'm not sure.

I somewhat agree about trying to keep the number of files down, but does it seem to you that scope.js has gotten a bit out of control? It's over 2k lines long. Maybe that's still easier than looking through multiple folders, though...

[BryceStevenWilley]

Yeah, I do agree that scope.js is a bit big (it is about 1/3rd comments though, it's 1243 logical lines (not empty lines and not comments), which is big but IMO isn't too big). I just wanted to caution about trying to refactor everything so it's in "the right file" too. For sure I'm not a fan of starting to nest folders if I have to jump back and forth between the different folders all the time (as I've been having to in the Efile proxy, since Java forces you have separate files for each class).