Hello all!
I recently switched from old way - including parent object files into derived class, even though they were marked as shared - to defining externals. So previously I had:
-- foo.as
shared abstract class Foo
{
}
-- bar.as
#include "foo.as"
shared class Bar: Foo
{
}
It caused some problems because every final module was littered by previous modules, line numbers in exceptions would not match and so on. Now I have it like this:
-- bar.as
external shared class Foo;
shared class Bar: Foo
{
}But if the derived class uses some other classes from previous modules, it all has to be typed as 'external' or cause syntax errors. With some deeper hierarchy it may be a lot of boilerplate. I was thinking how to automate it while keeping a bit more explicit (don't want complete magic under the hood). My suggestion is to introduce a special keyword 'require':
-- bar.as
require "foo.as"
shared class Bar: Foo
{
}This would be equivalent to iterating over all shared entities in foo.h (and also its own requires) and automatically externalling them for current module.
Another way would be some sort of "export" keyword in the files that name some kind of "shared module" entity, so instead of require "foo.as" we could write require Foo; and it would know what it means as long as foo.as was compiled earlier.
Do you think having such one-line require for a given file rather than having to specify all externals used by given file by hand would be useful?
For now I will probably introduce some #pragma that may do something like the above, but I thought maybe there is some idea already in progress that would make the usage of shared entites a bit more convenient?
