Slots
Locked
12
12
 
|
I notice that "Slots" are slated for addition in Pharo 3.0. Is there
anywhere I can see which model of "slots" is being suggested? I'm not sure that slots, in the sense of Javascript, are a good idea generally and, in the broader context, I'm very unhappy with the idea of messing with Smalltalk's generally clean syntax by adding new language features. Could the desired effects be achieved by subclassing Behavour or somesuch high-level approach? -- Thomas Worthington |
|
|
Some links on http://stackoverflow.com/questions/15609209/why-instancevariablenames-is-a-string-and-not-a-more-structured-collection/15615012#15615012
On Mon, Apr 1, 2013 at 12:28 PM, Thomas Worthington <[hidden email]> wrote: > I notice that "Slots" are slated for addition in Pharo 3.0. Is there > anywhere I can see which model of "slots" is being suggested? I'm not sure > that slots, in the sense of Javascript, are a good idea generally and, in > the broader context, I'm very unhappy with the idea of messing with > Smalltalk's generally clean syntax by adding new language features. Could > the desired effects be achieved by subclassing Behavour or somesuch > high-level approach? > > -- > Thomas Worthington > -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill |
|
|
In reply to this post by Thomas Worthington-2
On Apr 1, 2013, at 12:28 PM, Thomas Worthington <[hidden email]> wrote: > I notice that "Slots" are slated for addition in Pharo 3.0. Is there anywhere I can see which model of "slots" is being suggested? http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLayouts.pdf > I'm not sure that slots, in the sense of Javascript, are a good idea generally and, in the broader context, I'm very unhappy with the idea of messing with Smalltalk's generally clean syntax by adding new language features. Could the desired effects be achieved by subclassing Behavour or somesuch high-level approach? The good news is that there are -> no vm changes -> no changes in the syntax So maybe it is done exactly as you suggest? I guess. For the integration, there are two steps 1) Layouts and new classBuilder This change is purely internal. There are Slot objects describing instance variables, but there are actually no new slot types and the definition template for subclassing is unchanged. You can look at an image like that here: https://ci.inria.fr/pharo-contribution/job/Slot/ 2) Actually add new Slots and support in the tools for those. Marcus |
|
Administrator
|
Sounds exciting! I particularly like the built-in verification of values and even relationship to data, possibly in other objects!
Cheers,
Sean |
|
|
Slots (first class instance variables) open a lot of new way of doing things :)
I'm dreaming about them. They are cruelly missing in Smalltalk. Stef > Marcus Denker-4 wrote >> http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLayouts.pdf > > Sounds exciting! I particularly like the built-in verification of values and > even relationship to data, possibly in other objects! > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Slots-tp4679183p4679204.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > |
|
|
In reply to this post by Thomas Worthington-2
So Pharo 3 is out, slots are listed in changelog, but how to use them? Any examples (those in paper don't work)?
|
|
|
+1 on the question actually, I think it may help with some hacky stuff that I am doing right now for my research :-) On May 17, 2014, at 5:10 PM, webwarrior <[hidden email]> wrote: > So Pharo 3 is out, slots are listed in changelog, but how to use them? Any > examples (those in paper don't work)? > > > > -- > View this message in context: http://forum.world.st/Slots-tp4679183p4759385.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile |
|
|
Hello, So I'd say there's a few work to do to use them, but if someone do this work, it will be integrated for Pharo 4. Marcus, Camille, Martin, you know more than me about slots what do you think ?
2014-05-17 23:36 GMT+02:00 Johan Fabry <[hidden email]>:
|
|
|
I understand, thanks for the info. Let me simplify my question: Using slots is there a reasonably straightforward way for me to intercept variable accesses in all methods within a class? This so that I can transparently redirect them to a dictionary lookup. Or am I going to have to override instVarNamed: and hope that works always? On May 18, 2014, at 3:50 AM, Clément Bera <[hidden email]> wrote: > Hello, > > Actually slots are introduced so we can use them the next Pharo iteration (Pharo 4). It is difficult to use as it is, you need to change a bit the compiler so that it asks the class slots for field access byte code generation (a field being typically an instance variable) and you also need to improve the class builder in a way that you would have a class template where you can set specific slot for each field. Then you can subclass slots and use them. > > So I'd say there's a few work to do to use them, but if someone do this work, it will be integrated for Pharo 4. > > Marcus, Camille, Martin, you know more than me about slots what do you think ? > > > 2014-05-17 23:36 GMT+02:00 Johan Fabry <[hidden email]>: > > +1 on the question actually, I think it may help with some hacky stuff that I am doing right now for my research :-) > > On May 17, 2014, at 5:10 PM, webwarrior <[hidden email]> wrote: > > > So Pharo 3 is out, slots are listed in changelog, but how to use them? Any > > examples (those in paper don't work)? > > > > > > > > -- > > View this message in context: http://forum.world.st/Slots-tp4679183p4759385.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile |
|
|
2014-05-18 21:42 GMT+02:00 Johan Fabry <[hidden email]>:
Yes. This is easy to do with slots.
Basically you need to define your own slot and mark the instance variables you want to intercept to use this specific slot (in your case, all the instance variables). Then all instance variable access will be compiled with your indirection.
This so that I can transparently redirect them to a dictionary lookup. Yes, you can do that with slots. However we were discussing about that recently with some VM guys, and this may be quite slow on our VM. One language that runs on our VM, NewSpeak, have similar features (indirection for all instance variable access) and it is difficult for them to have good performance. This dictionary lookup case is optimized in prototype-based language VMs (Self, Javascript). Usually for users it appears that there is an indirection with a dictionary, but the implementation does not rely on dictionary for performance.
Or am I going to have to override instVarNamed: and hope that works always? I guess you will also have to override instVarNamed: and/or instVarAt: if you want to catch reflexive instVar access. But that will never always work this method is only for reflective access.
|
|
|
In reply to this post by jfabry
On 18 May 2014, at 21:42, Johan Fabry <[hidden email]> wrote: > > I understand, thanks for the info. > > Let me simplify my question: Using slots is there a reasonably straightforward way for me to intercept variable accesses in all methods within a class? Yes, you can make a special slot subclass and this defines than the semantics of the slot. You have full control of what code to emit. > This so that I can transparently redirect them to a dictionary lookup. there will be Dictionay based slots coming with Pharo4, no need to roll your own for that. In addition, I want to add support for Reflectivity meta links on slots. This means that instead of changing the class definition, you will be able to put a MetaLink on the slot definition (before, after, around/instead). This is for the more “reflective” use cases. Now this is all in an early state.. the idea is to finish all this over the summer :-) With Camille we did a quick 20 minute prototype of the whole thing: Subclass of Slot. Opal calles #emitStore: and #emitRead: on slots. the abstract slot has a fall-back that just uses reflection: emitValue: aMethodBuilder aMethodBuilder pushLiteral: self; pushReceiver; send: #read: while you can implement it yourself and emit the bytecode that you need. e.g. for the ivarSlot subclass it is emitValue: methodBuilder methodBuilder pushInstVar: index. making Ivar Slots be as efficient as instance variables now. Marcus |
|
|
In reply to this post by Clément Béra
On 19 May 2014, at 07:24, Clément Bera <[hidden email]> wrote:
The nice thing with the Slot idea is that by default, everyone will just use InstanceVariableSlots which are as fast as now. (the current image, all slots are ivars, or all ivars are Slots instances). You will only use Dictionary Slots when you *really* need them (e.g. Morph could merge most of MorphExtension into Dictioarny and BooleanSlots… it would even be more memory efficient and faster than now...
instVarAt:, as it reasons about offsets, is very low level…. for slots, it makes not much sense (as they do not have offsets). But the idea is to provide a reasonable reflective API…. e.g. slotNamed: (and maybe instVarNamed: is just an alias of that) will of course delegate to the slot for reading, taking your semantic change into account. Marcus |
|
|
In reply to this post by Marcus Denker-4
On 19 mai 2014, at 14:06, Marcus Denker <[hidden email]> wrote: > > On 18 May 2014, at 21:42, Johan Fabry <[hidden email]> wrote: > >> >> I understand, thanks for the info. >> >> Let me simplify my question: Using slots is there a reasonably straightforward way for me to intercept variable accesses in all methods within a class? > > Yes, you can make a special slot subclass and this defines than the semantics of the slot. You have full control of what code to emit. > >> This so that I can transparently redirect them to a dictionary lookup. > > there will be Dictionay based slots coming with Pharo4, no need to roll your own for that. > > In addition, I want to add support for Reflectivity meta links on slots. This means that instead of changing the class definition, > you will be able to put a MetaLink on the slot definition (before, after, around/instead). This is for the more “reflective” use cases. > > Now this is all in an early state.. the idea is to finish all this over the summer :-) > > With Camille we did a quick 20 minute prototype of the whole thing: Subclass of Slot. Yes it was fun :) To experiment, we did a really simple kind of slot we called ClassSlot that is equivalent to our current class variables. > Opal calles #emitStore: and #emitRead: > on slots. the abstract slot has a fall-back that just uses reflection: > > emitValue: aMethodBuilder > aMethodBuilder > pushLiteral: self; > pushReceiver; > send: #read: > > while you can implement it yourself and emit the bytecode that > you need. e.g. for the ivarSlot subclass it is > > emitValue: methodBuilder > > methodBuilder pushInstVar: index. > > making Ivar Slots be as efficient as instance variables now. > > Marcus > |
|
|
One more question. Can all this provide a possibility (in the future) to add inst vars to classes of the foreign packages?
Uko On 19 May 2014, at 14:33, Camille Teruel <[hidden email]> wrote:
|
|
|
In reply to this post by camille teruel
On 19 May 2014, at 14:33, Camille Teruel <[hidden email]> wrote: > > On 19 mai 2014, at 14:06, Marcus Denker <[hidden email]> wrote: > >> >> On 18 May 2014, at 21:42, Johan Fabry <[hidden email]> wrote: >> >>> >>> I understand, thanks for the info. >>> >>> Let me simplify my question: Using slots is there a reasonably straightforward way for me to intercept variable accesses in all methods within a class? >> >> Yes, you can make a special slot subclass and this defines than the semantics of the slot. You have full control of what code to emit. >> >>> This so that I can transparently redirect them to a dictionary lookup. >> >> there will be Dictionay based slots coming with Pharo4, no need to roll your own for that. >> >> In addition, I want to add support for Reflectivity meta links on slots. This means that instead of changing the class definition, >> you will be able to put a MetaLink on the slot definition (before, after, around/instead). This is for the more “reflective” use cases. >> >> Now this is all in an early state.. the idea is to finish all this over the summer :-) >> >> With Camille we did a quick 20 minute prototype of the whole thing: Subclass of Slot. > > Yes it was fun :) > To experiment, we did a really simple kind of slot we called ClassSlot that is equivalent to our current class variables. > AbstractSlot subclass: #TestSlot instanceVariableNames: 'value' classVariableNames: '' category: 'Slot-Scope’ we just implement the reflective read and write (not bothering to emit optimised bytecode): read: anObject ^ value write: aValue to: anObject value := aValue a method iv ^ iv of a class here iv is such a special class slot is compiled to 21 <20> pushConstant: a TestSlot 22 <70> self 23 <E1> send: read: 24 <7C> returnTop |
|
|
In reply to this post by Uko2
On 19 May 2014, at 14:38, Yuriy Tymchuk <[hidden email]> wrote: > One more question. Can all this provide a possibility (in the future) to add inst vars to classes of the foreign packages? > it definitly would be easier to do as ivars (like all slots) are objects… that could be “part” of a package, like methods are now allready. Marcus |
|
|
In reply to this post by Marcus Denker-4
On 19 mai 2014, at 14:11, Marcus Denker <[hidden email]> wrote:
Rather, I think that instVarXXX methods (or equivalent) should be exposed in a low-level API as it deals with an object actual representation in memory whereas slotXXX methods should be exposed in a high level API as it's closer to the application domain and to the programmer's intent. This is an example of the problems we get when we want to add new concepts and features to Pharo. The problem lies in the interaction between two interweaved languages: - the high-level language we use to develop - the low-level language that the runtime (VM) executes. Currently, both languages are merged (especially in the light of reflection) as their concepts are supposed to map. But when we introduce something like slots, we mess with this fragile ecosystem since the concepts of both languages doesn't map anymore (field ~= slots). There is basically two solutions, either we adapt the runtime to close the semantic gap introduced by the new language feature to reunify the LL and HL languages or we explicitly keep both languages. The first solution requires manpower and the work has to be done each time a new feature is introduced. If on the contrary we expect our language to evolve, the second solution is better: just another level of indirection. We have an evolvable language of smalltalkish code, slots and theNewCoolConcept that compiles to an almost fixed language of bytecodes and field offsets. I think we need this distinction and I'm working on it.
|
|
|
In reply to this post by Marcus Denker-4
On May 19, 2014, at 8:06 AM, Marcus Denker <[hidden email]> wrote: >> This so that I can transparently redirect them to a dictionary lookup. > > there will be Dictionay based slots coming with Pharo4, no need to roll your own for that. > > In addition, I want to add support for Reflectivity meta links on slots. This means that instead of changing the class definition, > you will be able to put a MetaLink on the slot definition (before, after, around/instead). This is for the more “reflective” use cases. > > Now this is all in an early state.. the idea is to finish all this over the summer :-) OK I declare that I’m a customer for dictionary-based slots. Please keep me up to date on progress :-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile |
|
|
> Am 19.05.2014 um 19:58 schrieb Johan Fabry <[hidden email]>: > > > On May 19, 2014, at 8:06 AM, Marcus Denker <[hidden email]> wrote: > >>> This so that I can transparently redirect them to a dictionary lookup. >> >> there will be Dictionay based slots coming with Pharo4, no need to roll your own for that. >> >> In addition, I want to add support for Reflectivity meta links on slots. This means that instead of changing the class definition, >> you will be able to put a MetaLink on the slot definition (before, after, around/instead). This is for the more “reflective” use cases. >> >> Now this is all in an early state.. the idea is to finish all this over the summer :-) > > OK I declare that I’m a customer for dictionary-based slots. Please keep me up to date on progress :-) me, too! Norbert > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > |
|
|
So am I :) Doru On Mon, May 19, 2014 at 9:03 PM, Norbert Hartl <[hidden email]> wrote:
"Every thing has its own flow"
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |