June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Marcus Denker

On 25 Jun 2014, at 17:32, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 25 juin 2014, at 14:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> Hi, >> >> Already in Pharo3 all instance variables are described using meta-objects (so called slots). >> >> To make it easier to access the slots, I added some simple methods to ClassDescription on 4.0 043, >> Now we can do e.g.: >> >> Context slots >> Context allSlots >> >> Point hasSlotNamed: #x >> Point slotNamed: #x >> >> e.g. the slot âxâ of Point knows how to reflectively read itself from a point: >> >> (Point slotNamed: #x) read: 5@3 > > Now we should be careful that the reflective APIs for slots at object-level and at class-level don't clash. > What I means is that if "Point slotNamed: #x" return a slot what is the selector that satisfies "Point ?: #superclass" --> Object. > > It's difficult to have an elegant and consistent naming scheme because we lack precise terminology. > For example when we talk about an instance variable, do we refer to the declaration of an iv in a class or to the value bound to an iv in a given instance of that class? > Right now it is not clear: compare current class-level reflective API (#hasInstVarNamed: #instVarNames & co) to the object-level one (#instVarNamed: #instVarNamed:put: & co). > I'm afraid that if we don't pay attention, we will have the same confusion when talking about slots. > > A slot is the *specification* of a variable that is accessible to the instances of a class. > So I think that the term slot should be reserved for methods of the class-level reflective API, as Marcus proposes with these new methods. > > So now what should be the new reflective API at the object-level? > Note that a slot doesn't necessarily define an instance variable, a slot could represent a shared variable like a class variable for example. > So I'm not sure that #instVarNamed: and #instVarNamed:put are still good names (even if they are backward compatible)... > Maybe #variableNamed: and #variableNamed:put:? > Or #valueOfSlotNamed: and #setValueOfSlotNamed:to:? > I think I dislike both, so I hope you have better ideas :) > > Sorry to be the annoying nitpicker :), I know I tend to be fussy with terminology. > But terminology determines APIs: ill-defined terminology is a step towards bad APIs. > Yesâ¦ the problem is that the âSlot meta objectâ and the âSlot that stores somethingâ use the same nameâ¦ this was not a problem for instance variables as the where not reified. maybe on the class side it could be Point slotDefinitionNamed: but nice it is notâ¦ or we maybe we use #resolveSlot: as the layoutâ¦. Marcus

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Camille Teruel

On 25 juin 2014, at 17:06, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 25.06.2014 um 16:55 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > >> 2014-06-25 11:52 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>> >>> On 25 Jun 2014, at 11:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> >>>> On 25 Jun 2014, at 16:43, Esteban A. Maringolo <emaringolo(a)gmail.com> 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 >> >> What about SimpleInstanceVariableSlot? (just kidding) >> >> I don't like over descriptive class names. Because they restrict you >> from using it for other, unexpected, purposes or contexts. >> > > The question to me is why this is "over descriptive". We have a tradition here to be descriptive and intention revealing. It happens everywhere except when it comes to instance variables it is instVarAt: instVarNamed: etc. I never liked them. > Another question might be the usage context. Why is it called InstanceVariableSlot anyway? > Is there a difference if the slot is attached to the instance side or class side? No indeed there is no difference, an iv slot attached to the class side is still an instance variable slot that happens to be declared in a metaclass and assigned in its unique instance and in its many subinstances. > Isn't it really just a VariableSlot? It sounds too generic to me as custom slots can represent other kind of variables like class-variables: ClassSlot>>read: anObject ^ value ClassSlot>>write: anObject to: aValue value := aValue Note that iv slots are the default kind of slot, so no matter how long it seems to type InstanceVariableSlot, you won't have to type it. For example the current class builder can be used like this: PharoClassInstaller make: [ :builder | builder name: #MyClass; slots: { #a. #b => CustomSlot } ]. #a will be a slot of the default kind (currently named Slot) and #b will be a CustomSlot. > The context for the instance is where it is used. Asking an object for instance variables and class instance variables could just return a collection of VariableSlots, no? > Norbert

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Camille Teruel

On 25 juin 2014, at 14:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Already in Pharo3 all instance variables are described using meta-objects (so called slots). > > To make it easier to access the slots, I added some simple methods to ClassDescription on 4.0 043, > Now we can do e.g.: > > Context slots > Context allSlots > > Point hasSlotNamed: #x > Point slotNamed: #x > > e.g. the slot âxâ of Point knows how to reflectively read itself from a point: > > (Point slotNamed: #x) read: 5@3 Now we should be careful that the reflective APIs for slots at object-level and at class-level don't clash. What I means is that if "Point slotNamed: #x" return a slot what is the selector that satisfies "Point ?: #superclass" --> Object. It's difficult to have an elegant and consistent naming scheme because we lack precise terminology. For example when we talk about an instance variable, do we refer to the declaration of an iv in a class or to the value bound to an iv in a given instance of that class? Right now it is not clear: compare current class-level reflective API (#hasInstVarNamed: #instVarNames & co) to the object-level one (#instVarNamed: #instVarNamed:put: & co). I'm afraid that if we don't pay attention, we will have the same confusion when talking about slots. A slot is the *specification* of a variable that is accessible to the instances of a class. So I think that the term slot should be reserved for methods of the class-level reflective API, as Marcus proposes with these new methods. So now what should be the new reflective API at the object-level? Note that a slot doesn't necessarily define an instance variable, a slot could represent a shared variable like a class variable for example. So I'm not sure that #instVarNamed: and #instVarNamed:put are still good names (even if they are backward compatible)... Maybe #variableNamed: and #variableNamed:put:? Or #valueOfSlotNamed: and #setValueOfSlotNamed:to:? I think I dislike both, so I hope you have better ideas :) Sorry to be the annoying nitpicker :), I know I tend to be fussy with terminology. But terminology determines APIs: ill-defined terminology is a step towards bad APIs. > > ==> 5 > > Marcus

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Esteban A. Maringolo

2014-06-25 12:06 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > Am 25.06.2014 um 16:55 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > I don't like over descriptive class names. Because they restrict you > from using it for other, unexpected, purposes or contexts. > The question to me is why this is "over descriptive". We have a tradition > here to be descriptive and intention revealing. It happens everywhere except > when it comes to instance variables it is instVarAt: instVarNamed: etc. I > never liked them. I agree with you here, it is like those instVar* selectors are obfuscated only to show they are "low level stuff". > Another question might be the usage context. Why is it called > InstanceVariableSlot anyway? Is there a difference if the slot is attached > to the instance side or class side? Isn't it really just a VariableSlot? The > context for the instance is where it is used. Asking an object for instance > variables and class instance variables could just return a collection of > VariableSlots, no? "Simplicity is the ultimate sophistication", so finding a good intention revealing selector is not an easy task. But IMO the naming is as important as other factors, because you'll keep referring them in many contexts, and that will help build good mental models. I like how VariableSlot sounds. But aren't slots meant to be used always in the context of variables? If so, Variable might be read as an attribute (that varies, in shape, etc.). Many of us are non native speakers, so this is an important factor too. Regards!

June 25, 2014

Re: [Pharo-dev] can I be added to the pharoextras team?

by Damien Cassou

On Wed, Jun 25, 2014 at 4:47 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > my sthub username is pdebruic done -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Marcus Denker

On 25 Jun 2014, at 14:22, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 25 Jun 2014, at 14:16, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Very nice! >> >> Next would be an example of how to specialize a slot :) >> > > Yes, the next steps are: > > - introduce abstract superclass for Slot > For now there is a subclass InstanceVariableSlot, all Slot instances have been migrated. > - Opal needs to delegate code generation to the Slot. > This is now done. Opal now, in the semantic analysis phase, annotates slot accesses as OCSlotVariable (OCInstanceVariable we can remove later). Then when generating, it just forwards to the slot: emitStore: methodBuilder slot emitStore: methodBuilder To allow Slots subclasses to be implemented without knowledge of bytecode, the next thing to add it the fallback: > - The abstract slot generates by default reflective read/write access code Marcus

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Norbert Hartl

Am 25.06.2014 um 16:55 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > 2014-06-25 11:52 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> On 25 Jun 2014, at 11:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On 25 Jun 2014, at 16:43, Esteban A. Maringolo <emaringolo(a)gmail.com> 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 > > What about SimpleInstanceVariableSlot? (just kidding) > > I don't like over descriptive class names. Because they restrict you > from using it for other, unexpected, purposes or contexts. > The question to me is why this is "over descriptive". We have a tradition here to be descriptive and intention revealing. It happens everywhere except when it comes to instance variables it is instVarAt: instVarNamed: etc. I never liked them. Another question might be the usage context. Why is it called InstanceVariableSlot anyway? Is there a difference if the slot is attached to the instance side or class side? Isn't it really just a VariableSlot? The context for the instance is where it is used. Asking an object for instance variables and class instance variables could just return a collection of VariableSlots, no? Norbert

June 25, 2014

Re: [Pharo-dev] [Tutorial] Rediscovering the UX of the legendary HP-35 Scientific Pocket Calculator

by Sven Van Caekenberghe

Apparently it already got posted on YC News https://news.ycombinator.com/item?id=7943876 so it needs votes and comments to survive. On 25 Jun 2014, at 15:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I have written a new, extensive, long form, introductory article about Pharo. > > Rediscovering the UX of the legendary HP-35 Scientific Pocket Calculator > > A tutorial on Pharo, test and specification based immersive programming > > https://medium.com/@svenvc/rediscovering-the-ux-of-the-legendary-hp-35-scie… >

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Esteban A. Maringolo

2014-06-25 11:52 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 25 Jun 2014, at 11:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 25 Jun 2014, at 16:43, Esteban A. Maringolo <emaringolo(a)gmail.com> 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 What about SimpleInstanceVariableSlot? (just kidding) I don't like over descriptive class names. Because they restrict you from using it for other, unexpected, purposes or contexts. Regards!

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by Esteban Lorenzano

On 25 Jun 2014, at 11:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 25 Jun 2014, at 16:43, Esteban A. Maringolo <emaringolo(a)gmail.com> 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 <norbert(a)hartl.name>: >>> >>> Am 25.06.2014 um 14:22 schrieb Marcus Denker <marcus.denker(a)inria.fr>: >>> >>>> >>>> On 25 Jun 2014, at 14:16, Tudor Girba <tudor(a)tudorgirba.com> 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 >>>> >>>> >>> >>> >> > >

June 25, 2014