[Pharo-project] Class Builder for Pharo, was Re: Improving Pharo's Exception Hierarchy
toon.verwaest at gmail.com
Thu Apr 14 20:18:26 CEST 2011
On 04/14/2011 08:09 PM, Stéphane Ducasse wrote:
> On Apr 14, 2011, at 4:12 PM, Toon Verwaest wrote:
>> Be patient, be patient ;)
>> I'm still very busy at the moment, but it'll get there.
>> We'll probably have discuss if you want to generate slot and layout objects in the classbuilder, or if you want to replace the instanceVariables array with real layout objects that you keep around. We basically implemented everything around the layout objects and keep this data in all classes; but you'll have to figure out if you want this in Pharo or not. Decide and let me know, I'd say ;)
> you know the answer (we want slots). After this is more a question of
> - is the code robust
> - what are the migration plans
> - do we schedule that for when
Well for robustness reasons I suggest to start the port with only
layouts and 1 type of slot object (the standard slot object). This slot
object will in the first phase not influence compilation at all. We can
also (in the first phase) keep the class format exactly the same as it
was before, to not interfere with existing tools and code.
This makes the layouts only metadata that is used by the class builder
and the interface between the compiler and classes. The inspector can
easily be rewritten to also use the slot metaobjects.
If we do it in that format, I can tell you that layouts are stable and
so is the migration. I can remove the decompilation/recompilation based
on Opal for fast method rewriting for now, if you want to avoid too many
dependencies at first and test the whole class builder independent of
how methods are updated. This is basically just 1 line of code that
needs to be changed so I can easily disable that ...
If you give me an exact plan and an image into which I can bootstrap my
classbuilder, I can do this first step by myself. Someone with more
knowledge of the whole ecosystem could then help me to smooth out the
The only thing that isn't working yet atm is the class globals (the
class variables), but that isn't really hard; it just needs to be done :)
I really didn't care about that part, which is why it isn't there yet.
Obviously my suggestion means that you won't have slots yet in the
beginning, but I think that's the safest bet for now. The classbuilder
works and doesn't introduce new concepts yet. It just cleans up existing
More information about the Pharo-project