On 25 Jun 2014, at 11:49, Marcus Denker <[email protected]> wrote:
> > On 25 Jun 2014, at 16:43, Esteban A. Maringolo <[email protected]> wrote: > >> Slot >> \SimpleSlot (current iv slot) > > Yes, the naming of that one… I think we just need to take the freedom of > iterating. > For now I called it “InstanceVariableSlot”, but that might be confusing and > it is a long word. but is less confusing than “SimpleSlot”, which basically says nothing, IMO > >> \CollectionSlot >> \BitmapSlot >> Esteban A. Maringolo >> >> >> 2014-06-25 9:38 GMT-03:00 Norbert Hartl <[email protected]>: >>> >>> Am 25.06.2014 um 14:22 schrieb Marcus Denker <[email protected]>: >>> >>>> >>>> On 25 Jun 2014, at 14:16, Tudor Girba <[email protected]> wrote: >>>> >>>>> Very nice! >>>>> >>>>> Next would be an example of how to specialize a slot :) >>>>> >>>> >>>> Yes, the next steps are: >>>> >>>> - introduce abstract superclass for Slot >>>> >>>> (I am not yet sure: will the be “Slot” and the default slots are >>>> “InstVarSlot”, or do I add a >>>> “AbstractSlot” class and Slot stays the default? Maybe that’s better) >>>> >>> I like the former better. But if you do can you please help stop that >>> naming scheme? Could we name it InstanceVariableSlot then? Pleeeeaaaase? >>> >>> Norbert >>> >>>> - Opal needs to delegate code generation to the Slot. >>>> >>>> - The abstract slot generates by default reflective read/write access code >>>> >>>> - subclasses can override. (e.g. the default slot overrides to do >>>> pushIvar/storeIvar bytecode) >>>> >>>> This is the enough to do behavioural changes to simple Slots. >>>> >>>> After that we need to check the code for “virtual” slots where e.g. >>>> multiple Boolean slots are mapped to one >>>> hidden flag ivar. >>>> >>>> And the of course >>>> >>>> - new class template (optional at first) >>>> - Monticello support >>>> >>>> Marcus >>>> >>>> >>> >>> >> > >
