Abstract Object

[telephon]

Here is a new RFC – let me know what you think …

[JordanHendersonMusic]

I really like this idea, both in terms of putting object on a diet, and having more robust wrappers.

Here's some initial thoughts:

Would this affect how the classes are initialized? Currently object is partially declared first, then class, and then they are patched together.

Could we rename some of the necessary methods in abstractObject to longer names that are less likely to collide. gcDumpGrey, could be called builtin__GCDumpGrey and object could lower it to the shorter name, preserving backwards compatibility. This way there is less chance of collision and the wrapper becomes more pure. Also, we could have a soft rule saying no double underscores as these are preserved for built-ins?

[telephon]

Would this affect how the classes are initialized? Currently object is partially declared first, then class, and then they are patched together.

This is something I don't know enough about. It certainly would take some extra care to get this right.

Could we rename some of the necessary methods in abstractObject to longer names that are less likely to collide. gcDumpGrey, could be called builtin__GCDumpGrey and object could lower it to the shorter name, preserving backwards compatibility. This way there is less chance of collision and the wrapper becomes more pure. Also, we could have a soft rule saying no double underscores as these are preserved for built-ins?

That's a good idea, but I think the methods are needed for sclang. Of course maybe their names could be changed in the backend. I had heuristically tested in the Neutral Quark what subset can be omitted without breaking the runtime...

The difficult decision is what part of the interface should be kept in AbstractObject. This is something that is somewhat arbitrary and cannot be changed later.

[JordanHendersonMusic]

Of course maybe their names could be changed in the backend

That's what I was thinking. Even class should be called builtin__class and things like performList, builtin__performList.

The difficult decision is what part of the interface should be kept in AbstractObject.

I'd say, only if it is called builtin__*.

Otherwise you're going to get a name collision --- which is one of the main reasons for this. Once everything in the backend is switched over to builtin__ there should be no need for any methods in abstractObject without the prefix.

One exception might be operators, but I can't think of any that the backend uses.

[telephon]

That would be nice of course. I wonder if not this could lead to problems when calls are forwarded by a method of a subclass to the primitive? Like those performList ones.

Also, the whole method forwarding aspect is very important for the whole thing, I think, because it is what makes the system really usable efficiently.

[JordanHendersonMusic]

Just thinking forward a little...

With proper wrappers we could introduce a new keyword and syntax so this could be evaluated at runtime.

~foo = protoclass {
   protovar <a = 10;
   var <>b;
   *new { ... }
   bar { ... }
};

~f = ~foo();
~f.b = ~foo.a;
~f.bar;

We could also add keywords for importing files where the global variables are turned into keys. This would give us a module system.

[telephon]

Good idea! There are a lot of things that may be done ths way.

I was always wondering if it is not better and simpler to have a dynamic method table. This would be more smalltalkish. But that would incur some unknown cost for method lookup ...

[JordanHendersonMusic]

to have a dynamic method table

You mean making gRowTable be a hash map? So you can add methods to classes at run time? I am unsure about this because it would mean you would be able to change class methods while the program is running which would have lots of odd implications. The code I showed above would return a new prototype class instance every time it is updated and ran, meaning the old instances remain unchanged. It could work, but might be best discussed in a different RFC.

[telephon]

Yes, that makes sense. A kind of automatic "lexical scoping" rule for instantialisation.