Class loading mechanism

[gaborsch]

Implement an import and autoloader mechaninsm for classes and functions.

Syntax:

From core, utils play Array, Chain, and Chain Link
Off core play Math

rainbow will be an Array
say cosine on Math taking 0

Packages are folders, classes are individual files. All folders and filenames should be lowercased, the non-alphanumeric characters should be replaced by underscore (_).

Syntax> [ {off|from} <package-name>] play <file-list> should find classes or functions in the defined package. The <package-name> is a list expression, and may contain folder names. Folder name can be anything like a Rockstar identifier (e.g a variable name). <file-list> is also a list expression, containing file names.

The files should be named according to the contained class or function.

The above example requires the following folder structure:

/core/utils/array.rock  -- defines class Array
/core/utils/chain.rock -- defines class Chain
/core/utils/chain_link.rock -- defines class Chain Link
/core/maths.rock   -- defines class Maths, creates a "static instance" called Maths, with a function called `cosine`

The packages and files should be resolved from different repositories, in the following order:

• Local working directory
• Local copy of the system classes
• rockstar.zip file from a global directory (it must be cached) -- we must provide a mechanism to upgrade on request

It is also possible to define individual functions in dedicated files, however the package structure makes no sense then, because functions will be always top level.

Also, it may worth to add a package declaration. This also enables shorthands for the import declarations:

Album: core, and util
play Chain, and Chain Link

[yodasodabob]

For extra poetic license, i wonder if rather than From core, utils play Array, Chain, and Chain Link the alternative From core to utils play Array, Chain, and Chain Link should be supported. I.e., allowing the use of to instead of a comma for the package path to make it flow better.

[gaborsch]

Well, we have a so-called "list syntax", where we can enumerate things. This syntax follows that rule: [from <list-of-identifiers>] play <list-of-identifiers>

The first list is the names of the packages (and subpackages, etc). core, utils means /core/utils folder, core means /core folder, and core, utils and collections means /core/utils/collections. I have no idea how would it be possible to add the to keyword in the latter two cases.

The second list is the name of the imported classes/files from the defined package, e.g. Array means /core/utils/array.rock.

[gaborsch]

Implemented.

[yodasodabob]

Having seen the way it's defined in the OOP.md spec now and the examples you use there, it makes a lot more sense and looks better than i thought.