[Pharo-project] Class Builder for Pharo, was Re: Improving Pharo's Exception Hierarchy

Toon Verwaest 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
>
> Stef
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 
problems.

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 
code.

cheers,
Toon



More information about the Pharo-project mailing list