[Pharo4] Slots can now be saved with MC
Hi, After some searching for a solution⦠that does not break backward-compatibility, I found a way to save classes that use slots. - if a class just uses ivar Slots, it saves it 100% backward compatible (e.g. loadable in other systems) - if a class uses a special slot or class var, it saves the definition of the slot as the variable name in the monticello model. - on load it checks if there is a space in a variable name, and if yes â> decode these as Slot/Global var definions. - the code path for non-Slot classes stays largely untouched. This is not beautiful but backward compatible⦠you can even load classes with Slots in Pharo3, it then creates invalid ivar names, which of course means the code does not run but it is readable. e.g. create a class like Object subclass: #A slots: { #iv => TestSlot } classVariables: { } category: 'Playgroundâ (TestSlot is a slot that does not use up space in the instance and instead saves the state in the Slot object, which means all instances share the state. Just a small example) Limitations -> no support for class variables yet -> class instance variables not yet done, either -> nut used much, for sure there will be bugs This is in 4.0 438 Marcus
Hi Marcus, On Fri, Jan 9, 2015 at 11:15 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
After some searching for a solution⦠that does not break backward-compatibility, I found a way to save classes that use slots.
- if a class just uses ivar Slots, it saves it 100% backward compatible (e.g. loadable in other systems) - if a class uses a special slot or class var, it saves the definition of the slot as the variable name in the monticello model. - on load it checks if there is a space in a variable name, and if yes â> decode these as Slot/Global var definions. - the code path for non-Slot classes stays largely untouched.
This is not beautiful but backward compatible⦠you can even load classes with Slots in Pharo3, it then creates invalid ivar names, which of course means the code does not run but it is readable.
e.g. create a class like
Object subclass: #A slots: { #iv => TestSlot } classVariables: { } category: 'Playgroundâ
(TestSlot is a slot that does not use up space in the instance and instead saves the state in the Slot object, which means all instances share the state. Just a small example)
Limitations -> no support for class variables yet -> class instance variables not yet done, either -> nut used much, for sure there will be bugs
This is in 4.0 438
Great news, great work! P.S. Maybe now Slots are ready for stealing by Squeak ;-) -- best, Eliot
On Fri, Jan 9, 2015 at 11:47 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2015, at 16:45, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Marcus,
P.S. Maybe now Slots are ready for stealing by Squeak ;-)
Everything I ever did for Pharo I wanted to do for Squeak⦠but I could not because someone was violently against it.
We will heal. It may take a long time, but we will. And things are going great right now, especially for Pharo. So I hope that your pain will ease and that one day you will be free of it. Hugs, and happy new year. And thanks for Slots and Opal and all the other wonderful things you do. Marcus
-- best, Eliot
Markus wrote:
Everything I ever did for Pharo I wanted to do for Squeak⦠but I could not because someone was violently against it.
Pharo now looks more and more what I dreamed about already back in the Squeak days. The toyish look is gone, the system gets cleaner and cleaner. Lots of tests, nice libs, CI infrastructure, easy image handling/downloading with launcher Still we are not there... Â Eliot wrote:
We will heal. It may take a long time, but we will.Â
I wonder how we can all come together again. It would help both sides to grow. Squeak facilities could sit on top of Pharo. Maybe with a cleaner morphic like Bloc. Phratch shows that this is possible. Things I currently miss in Pharo that were cool to use and demo in Squeak: - Support for more media and devices (video, mp3, sound recording/replaying, cam, joystick, ...) - Collaboration tools: - Shared worlds/remote views similar to Nebraska (to collaborate on code or remote interact with an image) and Telemorphic - Text and Audio Chat application, possibly video chat - Sending morphs over the network (using the Badge morph) - Shared world (Morphic) projects/Image segments - Bookmorphs (putting some text and graphic, saving as *.book, loading later again or sending to others) Also it would be supercool if Pharo images would run on Berts SqueakJS... Bye T.
It has been a while since I read the paper, but my memory is that Slots lets you define features and/or constraints on inst-var's. For example, assigning default values or restricting the set of valid values. This would probably be appealing for folks coming from languages like Java or C++, because they're used to all of their "slots" being statically typed. It does seem ironic that where those static languages have been trying to move toward being more dynamic, Pharo newbies would find themselves arrived at a language which is trying to make something that was purely dynamic into something more static. My understanding is that specifying a certain Slot-type can save the need to write, i.e., initializing or validating methods. In exchange, the number of concepts inherent in the language that must be learned and remembered is increased. Standard Smalltalk is only about 2 or 3 concepts -- sending messages and assigning pointers. Period. There's something exciting about that because even Grandma can grok 2 or 3 concepts. No other language is so simple. By introducing the implicit behaviors of slots, the number of different conceptual interactions between code and the slots it references increases exponentially with the number of slot-types. I fear trying to explain them to Grandma will have her eyes starting to glaze... PS -- I hope no one would characterize me as "violently" against slots. It may simply be my own ignorance.. On Fri, Jan 9, 2015 at 1:50 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Fri, Jan 9, 2015 at 11:47 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2015, at 16:45, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Marcus,
P.S. Maybe now Slots are ready for stealing by Squeak ;-)
Everything I ever did for Pharo I wanted to do for Squeak⦠but I could not because someone was violently against it.
We will heal. It may take a long time, but we will. And things are going great right now, especially for Pharo. So I hope that your pain will ease and that one day you will be free of it. Hugs, and happy new year. And thanks for Slots and Opal and all the other wonderful things you do.
Marcus
-- best, Eliot
@Chris, That sounds like a balance response. Its also been a while since I read it, and probably time I read it again and to have a play with slots (although last I heard it wasn't ready for prime time to do everything in the paper.) While the cognitive load might go up, I don't think its necessarily exponential. They way I think about it (blurred since I last read the paper) is that the assignment operator sort-of becomes a message send that you can redefine, and the slots are like mini-classes with limited scope - so there is a reuse of concepts. The complexity for grandma will all come down to the discoverability build into the tools - like how debugging interacts with slots. I don't think (and hope) it won't be much harder than learning to work with both an instance & class-side, and the difference between instance, class, class-instance and pool variables. On Mon, Jan 12, 2015 at 5:50 AM, Chris Muller <asqueaker@gmail.com> wrote:
It has been a while since I read the paper, but my memory is that Slots lets you define features and/or constraints on inst-var's. For example, assigning default values or restricting the set of valid values.
This would probably be appealing for folks coming from languages like Java or C++, because they're used to all of their "slots" being statically typed. It does seem ironic that where those static languages have been trying to move toward being more dynamic, Pharo newbies would find themselves arrived at a language which is trying to make something that was purely dynamic into something more static.
My understanding is that specifying a certain Slot-type can save the need to write, i.e., initializing or validating methods. In exchange, the number of concepts inherent in the language that must be learned and remembered is increased. Standard Smalltalk is only about 2 or 3 concepts -- sending messages and assigning pointers. Period. There's something exciting about that because even Grandma can grok 2 or 3 concepts. No other language is so simple.
By introducing the implicit behaviors of slots, the number of different conceptual interactions between code and the slots it references increases exponentially with the number of slot-types. I fear trying to explain them to Grandma will have her eyes starting to glaze...
PS -- I hope no one would characterize me as "violently" against slots. It may simply be my own ignorance..
On Fri, Jan 9, 2015 at 1:50 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Fri, Jan 9, 2015 at 11:47 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2015, at 16:45, Eliot Miranda <eliot.miranda@gmail.com>
wrote:
Hi Marcus,
P.S. Maybe now Slots are ready for stealing by Squeak ;-)
Everything I ever did for Pharo I wanted to do for Squeak⦠but I could not because someone was violently against it.
We will heal. It may take a long time, but we will. And things are going great right now, especially for Pharo. So I hope that your pain will ease and that one day you will be free of it. Hugs, and happy new year. And thanks for Slots and Opal and all the other wonderful things you do.
Marcus
-- best, Eliot
On 11 Jan 2015, at 18:50, Chris Muller <asqueaker@gmail.com> wrote:
It has been a while since I read the paper, but my memory is that Slots lets you define features and/or constraints on inst-var's. For example, assigning default values or restricting the set of valid values.
This would probably be appealing for folks coming from languages like Java or C++, because they're used to all of their "slots" being statically typed. It does seem ironic that where those static languages have been trying to move toward being more dynamic, Pharo newbies would find themselves arrived at a language which is trying to make something that was purely dynamic into something more static.
It is *possible* to implement a kind of TypedSlot, but I do not think that this is what people will use Slots for. And for sure there will be no TypeSlot by default in Pharo. For Slots there are two levels 1) having objects that describe variables instead of strings. This is very powerful already and will allow us to e.g. do watchpoints/breakpoitns in variables very easily This is already in Pharo3, but Pharo4 enhances the API and provides with the LinkWrapper slot a way to transparently hook into variable access. This will be very powerful. 2) provide a way to declare that a slot is described by a special subclass of Slot. This is what this change is about This is what we use Slots for are three directions: 1) active slots that announce when the are set. Replacing the whole ValueHolder stuf to some extend. (This is where Slots + their Meta Object Protocol allow one to implement the special variables in Tweak very easily. It is interesting that there, one had to copy the whole compiler and do many, many hacks. 2) Allow optimizing memory representation. E.g. look at Morph. Many flags are needed, but each takes a whole pinter to true of false. So we have MorphExtension. And then on top of that a property dictionary. With Slots, flags (sots that can only store true or false) can be realised very efficiently (31 boolean slots of the hierarchy map to one ivar). With a PropertySlot, one can have values that are used seldomely encoded in a way that they take no space. 3) Slots + Magritte. Magritte now relies of conventions and methods added to the class side. But what it is: meta descriptions for ivars. I think there will be something very powerful in combining Magritte and Slots. 4) Experiments. One way to see Pharo is that it is suppose to be flexible enough to allow experiments to be done fast and easy so we can explore many ideas easily. These experiments will often be just that: experiments. But some of them will be so good that they will turn out to be useful.
My understanding is that specifying a certain Slot-type can save the need to write, i.e., initializing or validating methods. In exchange, the number of concepts inherent in the language that must be learned and remembered is increased. Standard Smalltalk is only about 2 or 3 concepts -- sending messages and assigning pointers. Period. There's something exciting about that because even Grandma can grok 2 or 3 concepts. No other language is so simple.
Slots do not really increase the concepts: they just are meta objects that have the definition of the behaviour of assignment, turning assignment into message sends.
By introducing the implicit behaviors of slots, the number of different conceptual interactions between code and the slots it references increases exponentially with the number of slot-types. I fear trying to explain them to Grandma will have her eyes starting to glazeâ¦
I do not see now an active slot is harder to understand than e.g. a ValueHolder. or a BooleanSlot should be easier to understand than doing all that explicitely? Marcus
+ 1 Great post marcus. I want slots!!! and I want to have slot for caches because the analysis of guille showed that we have aroun 40 different caches in the system.... Stef Le 12/1/15 15:59, Marcus Denker a écrit :
On 11 Jan 2015, at 18:50, Chris Muller <asqueaker@gmail.com> wrote:
It has been a while since I read the paper, but my memory is that Slots lets you define features and/or constraints on inst-var's. For example, assigning default values or restricting the set of valid values.
This would probably be appealing for folks coming from languages like Java or C++, because they're used to all of their "slots" being statically typed. It does seem ironic that where those static languages have been trying to move toward being more dynamic, Pharo newbies would find themselves arrived at a language which is trying to make something that was purely dynamic into something more static.
It is *possible* to implement a kind of TypedSlot, but I do not think that this is what people will use Slots for. And for sure there will be no TypeSlot by default in Pharo.
For Slots there are two levels
1) having objects that describe variables instead of strings. This is very powerful already and will allow us to e.g. do watchpoints/breakpoitns in variables very easily
This is already in Pharo3, but Pharo4 enhances the API and provides with the LinkWrapper slot a way to transparently hook into variable access. This will be very powerful.
2) provide a way to declare that a slot is described by a special subclass of Slot. This is what this change is about
This is what we use Slots for are three directions:
1) active slots that announce when the are set. Replacing the whole ValueHolder stuf to some extend. (This is where Slots + their Meta Object Protocol allow one to implement the special variables in Tweak very easily. It is interesting that there, one had to copy the whole compiler and do many, many hacks.
2) Allow optimizing memory representation. E.g. look at Morph. Many flags are needed, but each takes a whole pinter to true of false. So we have MorphExtension. And then on top of that a property dictionary. With Slots, flags (sots that can only store true or false) can be realised very efficiently (31 boolean slots of the hierarchy map to one ivar). With a PropertySlot, one can have values that are used seldomely encoded in a way that they take no space.
3) Slots + Magritte. Magritte now relies of conventions and methods added to the class side. But what it is: meta descriptions for ivars. I think there will be something very powerful in combining Magritte and Slots.
4) Experiments. One way to see Pharo is that it is suppose to be flexible enough to allow experiments to be done fast and easy so we can explore many ideas easily. These experiments will often be just that: experiments. But some of them will be so good that they will turn out to be useful.
My understanding is that specifying a certain Slot-type can save the need to write, i.e., initializing or validating methods. In exchange, the number of concepts inherent in the language that must be learned and remembered is increased. Standard Smalltalk is only about 2 or 3 concepts -- sending messages and assigning pointers. Period. There's something exciting about that because even Grandma can grok 2 or 3 concepts. No other language is so simple.
Slots do not really increase the concepts: they just are meta objects that have the definition of the behaviour of assignment, turning assignment into message sends.
By introducing the implicit behaviors of slots, the number of different conceptual interactions between code and the slots it references increases exponentially with the number of slot-types. I fear trying to explain them to Grandma will have her eyes starting to glazeâ¦
I do not see now an active slot is harder to understand than e.g. a ValueHolder. or a BooleanSlot should be easier to understand than doing all that explicitely?
Marcus
Hi Marcus, On Jan 12, 2015, at 6:59 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 11 Jan 2015, at 18:50, Chris Muller <asqueaker@gmail.com> wrote:
It has been a while since I read the paper, but my memory is that Slots lets you define features and/or constraints on inst-var's. For example, assigning default values or restricting the set of valid values.
This would probably be appealing for folks coming from languages like Java or C++, because they're used to all of their "slots" being statically typed. It does seem ironic that where those static languages have been trying to move toward being more dynamic, Pharo newbies would find themselves arrived at a language which is trying to make something that was purely dynamic into something more static.
It is *possible* to implement a kind of TypedSlot, but I do not think that this is what people will use Slots for. And for sure there will be no TypeSlot by default in Pharo.
For Slots there are two levels
1) having objects that describe variables instead of strings. This is very powerful already and will allow us to e.g. do watchpoints/breakpoitns in variables very easily
This is already in Pharo3, but Pharo4 enhances the API and provides with the LinkWrapper slot a way to transparently hook into variable access. This will be very powerful.
2) provide a way to declare that a slot is described by a special subclass of Slot. This is what this change is about
This is what we use Slots for are three directions:
1) active slots that announce when the are set. Replacing the whole ValueHolder stuf to some extend. (This is where Slots + their Meta Object Protocol allow one to implement the special variables in Tweak very easily. It is interesting that there, one had to copy the whole compiler and do many, many hacks.
2) Allow optimizing memory representation. E.g. look at Morph. Many flags are needed, but each takes a whole pinter to true of false. So we have MorphExtension. And then on top of that a property dictionary. With Slots, flags (sots that can only store true or false) can be realised very efficiently (31 boolean slots of the hierarchy map to one ivar). With a PropertySlot, one can have values that are used seldomely encoded in a way that they take no space.
3) Slots + Magritte. Magritte now relies of conventions and methods added to the class side. But what it is: meta descriptions for ivars. I think there will be something very powerful in combining Magritte and Slots.
4) Experiments. One way to see Pharo is that it is suppose to be flexible enough to allow experiments to be done fast and easy so we can explore many ideas easily. These experiments will often be just that: experiments. But some of them will be so good that they will turn out to be useful.
I hope we'll also be able to follow a 5th direction, of allowing one to specify a slice or a trait or a package that just adds an inst var to a class instead of having to provide the whole class definition just to add an inst var.
My understanding is that specifying a certain Slot-type can save the need to write, i.e., initializing or validating methods. In exchange, the number of concepts inherent in the language that must be learned and remembered is increased. Standard Smalltalk is only about 2 or 3 concepts -- sending messages and assigning pointers. Period. There's something exciting about that because even Grandma can grok 2 or 3 concepts. No other language is so simple. Slots do not really increase the concepts: they just are meta objects that have the definition of the behaviour of assignment, turning assignment into message sends.
By introducing the implicit behaviors of slots, the number of different conceptual interactions between code and the slots it references increases exponentially with the number of slot-types. I fear trying to explain them to Grandma will have her eyes starting to glaze⦠I do not see now an active slot is harder to understand than e.g. a ValueHolder. or a BooleanSlot should be easier to understand than doing all that explicitely?
Marcus
I hope we'll also be able to follow a 5th direction, of allowing one to specify a slice or a trait or a package that just adds an inst var to a class instead of having to provide the whole class definition just to add an inst var.
We would love. With Epicea we have Changes representing not only class and instance addition/removal... Now the question is also how do we initialize such new added instance variable. Now we have probably to recompile the full class hierarchy. We are brainstorming on a modular way to initialize objects What are the paths to achieve that in a clever way.
Hi Stef On Jan 13, 2015, at 4:23 AM, stepharo <stepharo@free.fr> wrote:
I hope we'll also be able to follow a 5th direction, of allowing one to specify a slice or a trait or a package that just adds an inst var to a class instead of having to provide the whole class definition just to add an inst var.
We would love. With Epicea we have Changes representing not only class and instance addition/removal... Now the question is also how do we initialize such new added instance variable.
That's easy if the slot definition has an initialiser.
Now we have probably to recompile the full class hierarchy.
I don't see a way if avoiding this unless we move to a self/newspeak model of inst var accessor. But it can be made much faster than recompiling from source. The idea is simply to disassemble every method from bytecode to an assembler level representation (such as Marcus' byte surgeon or my method massage), adjust offsets and regenerate. This is what VisualWorks does and it is /much/ faster than recompiling from source.
We are brainstorming on a modular way to initialize objects What are the paths to achieve that in a clever way.
Yes the monolithic initialize method is an issue if one wants to be able to add inst vars individually. Lazy initialize toon in accessors is one way. That works well for eg inst vars used to implement caches (although now flushing becomes an issue). There's no such thing as a free lunch :-)
We would love. With Epicea we have Changes representing not only class and instance addition/removal... Now the question is also how do we initialize such new added instance variable. That's easy if the slot definition has an initialiser.
Now we have probably to recompile the full class hierarchy. I don't see a way if avoiding this unless we move to a self/newspeak model of inst var accessor. But it can be made much faster than recompiling from source. The idea is simply to disassemble every method from bytecode to an assembler level representation (such as Marcus' byte surgeon or my method massage), adjust offsets and regenerate.
This is what VisualWorks does and it is /much/ faster than recompiling from source.
Yes we should do that.
We are brainstorming on a modular way to initialize objects What are the paths to achieve that in a clever way. Yes the monolithic initialize method is an issue if one wants to be able to add inst vars individually. Lazy initialize toon in accessors is one way. That works well for eg inst vars used to implement caches (although now flushing becomes an issue). There's no such thing as a free lunch :-) I know :) Damien was working on a incremental initialization model with marco
Marcus, can you remind us where that Blog post you wrote about using slots is? A google search of âPharo Smalltalk slotsâ doesnât seem to find it, and I remember it being a great intro to what is possible. (Itâs worth considering tagging that post better - it should come up much higher in google search results). Tim On 12 Jan 2015, at 14:59, Marcus Denker <marcus.denker@inria.fr> wrote:
On 11 Jan 2015, at 18:50, Chris Muller <asqueaker@gmail.com> wrote:
It has been a while since I read the paper, but my memory is that Slots lets you define features and/or constraints on inst-var's. For example, assigning default values or restricting the set of valid values.
This would probably be appealing for folks coming from languages like Java or C++, because they're used to all of their "slots" being statically typed. It does seem ironic that where those static languages have been trying to move toward being more dynamic, Pharo newbies would find themselves arrived at a language which is trying to make something that was purely dynamic into something more static.
It is *possible* to implement a kind of TypedSlot, but I do not think that this is what people will use Slots for. And for sure there will be no TypeSlot by default in Pharo.
For Slots there are two levels
1) having objects that describe variables instead of strings. This is very powerful already and will allow us to e.g. do watchpoints/breakpoitns in variables very easily
This is already in Pharo3, but Pharo4 enhances the API and provides with the LinkWrapper slot a way to transparently hook into variable access. This will be very powerful.
2) provide a way to declare that a slot is described by a special subclass of Slot. This is what this change is about
This is what we use Slots for are three directions:
1) active slots that announce when the are set. Replacing the whole ValueHolder stuf to some extend. (This is where Slots + their Meta Object Protocol allow one to implement the special variables in Tweak very easily. It is interesting that there, one had to copy the whole compiler and do many, many hacks.
2) Allow optimizing memory representation. E.g. look at Morph. Many flags are needed, but each takes a whole pinter to true of false. So we have MorphExtension. And then on top of that a property dictionary. With Slots, flags (sots that can only store true or false) can be realised very efficiently (31 boolean slots of the hierarchy map to one ivar). With a PropertySlot, one can have values that are used seldomely encoded in a way that they take no space.
3) Slots + Magritte. Magritte now relies of conventions and methods added to the class side. But what it is: meta descriptions for ivars. I think there will be something very powerful in combining Magritte and Slots.
4) Experiments. One way to see Pharo is that it is suppose to be flexible enough to allow experiments to be done fast and easy so we can explore many ideas easily. These experiments will often be just that: experiments. But some of them will be so good that they will turn out to be useful.
My understanding is that specifying a certain Slot-type can save the need to write, i.e., initializing or validating methods. In exchange, the number of concepts inherent in the language that must be learned and remembered is increased. Standard Smalltalk is only about 2 or 3 concepts -- sending messages and assigning pointers. Period. There's something exciting about that because even Grandma can grok 2 or 3 concepts. No other language is so simple.
Slots do not really increase the concepts: they just are meta objects that have the definition of the behaviour of assignment, turning assignment into message sends.
By introducing the implicit behaviors of slots, the number of different conceptual interactions between code and the slots it references increases exponentially with the number of slot-types. I fear trying to explain them to Grandma will have her eyes starting to glazeâ¦
I do not see now an active slot is harder to understand than e.g. a ValueHolder. or a BooleanSlot should be easier to understand than doing all that explicitely?
Marcus
On 15 Jan 2015, at 13:04, Tim Mackinnon <tim@testit.works> wrote:
Marcus, can you remind us where that Blog post you wrote about using slots is? A google search of âPharo Smalltalk slotsâ doesnât seem to find it, and I remember it being a great intro to what is possible.
(Itâs worth considering tagging that post better - it should come up much higher in google search results).
There is no blog post yet⦠I want to actually have it finished, else I would write a post about something not working⦠which would be hard. Marcus
Tim
On 12 Jan 2015, at 14:59, Marcus Denker <marcus.denker@inria.fr> wrote:
On 11 Jan 2015, at 18:50, Chris Muller <asqueaker@gmail.com> wrote:
It has been a while since I read the paper, but my memory is that Slots lets you define features and/or constraints on inst-var's. For example, assigning default values or restricting the set of valid values.
This would probably be appealing for folks coming from languages like Java or C++, because they're used to all of their "slots" being statically typed. It does seem ironic that where those static languages have been trying to move toward being more dynamic, Pharo newbies would find themselves arrived at a language which is trying to make something that was purely dynamic into something more static.
It is *possible* to implement a kind of TypedSlot, but I do not think that this is what people will use Slots for. And for sure there will be no TypeSlot by default in Pharo.
For Slots there are two levels
1) having objects that describe variables instead of strings. This is very powerful already and will allow us to e.g. do watchpoints/breakpoitns in variables very easily
This is already in Pharo3, but Pharo4 enhances the API and provides with the LinkWrapper slot a way to transparently hook into variable access. This will be very powerful.
2) provide a way to declare that a slot is described by a special subclass of Slot. This is what this change is about
This is what we use Slots for are three directions:
1) active slots that announce when the are set. Replacing the whole ValueHolder stuf to some extend. (This is where Slots + their Meta Object Protocol allow one to implement the special variables in Tweak very easily. It is interesting that there, one had to copy the whole compiler and do many, many hacks.
2) Allow optimizing memory representation. E.g. look at Morph. Many flags are needed, but each takes a whole pinter to true of false. So we have MorphExtension. And then on top of that a property dictionary. With Slots, flags (sots that can only store true or false) can be realised very efficiently (31 boolean slots of the hierarchy map to one ivar). With a PropertySlot, one can have values that are used seldomely encoded in a way that they take no space.
3) Slots + Magritte. Magritte now relies of conventions and methods added to the class side. But what it is: meta descriptions for ivars. I think there will be something very powerful in combining Magritte and Slots.
4) Experiments. One way to see Pharo is that it is suppose to be flexible enough to allow experiments to be done fast and easy so we can explore many ideas easily. These experiments will often be just that: experiments. But some of them will be so good that they will turn out to be useful.
My understanding is that specifying a certain Slot-type can save the need to write, i.e., initializing or validating methods. In exchange, the number of concepts inherent in the language that must be learned and remembered is increased. Standard Smalltalk is only about 2 or 3 concepts -- sending messages and assigning pointers. Period. There's something exciting about that because even Grandma can grok 2 or 3 concepts. No other language is so simple.
Slots do not really increase the concepts: they just are meta objects that have the definition of the behaviour of assignment, turning assignment into message sends.
By introducing the implicit behaviors of slots, the number of different conceptual interactions between code and the slots it references increases exponentially with the number of slot-types. I fear trying to explain them to Grandma will have her eyes starting to glazeâ¦
I do not see now an active slot is harder to understand than e.g. a ValueHolder. or a BooleanSlot should be easier to understand than doing all that explicitely?
Marcus
Maybe it wasnât a blog post - but I definitely recall reading something last year that introduced the idea and showed some sample code (it wasnât a pdf). I thought it was really handy, and wanted to go back a read it in the context of this thread. Tim On 15 Jan 2015, at 18:04, Marcus Denker <marcus.denker@inria.fr> wrote:
On 15 Jan 2015, at 13:04, Tim Mackinnon <tim@testit.works> wrote:
Marcus, can you remind us where that Blog post you wrote about using slots is? A google search of âPharo Smalltalk slotsâ doesnât seem to find it, and I remember it being a great intro to what is possible.
(Itâs worth considering tagging that post better - it should come up much higher in google search results).
There is no blog post yet⦠I want to actually have it finished, else I would write a post about something not working⦠which would be hard.
Marcus
Tim
On 12 Jan 2015, at 14:59, Marcus Denker <marcus.denker@inria.fr> wrote:
On 11 Jan 2015, at 18:50, Chris Muller <asqueaker@gmail.com> wrote:
It has been a while since I read the paper, but my memory is that Slots lets you define features and/or constraints on inst-var's. For example, assigning default values or restricting the set of valid values.
This would probably be appealing for folks coming from languages like Java or C++, because they're used to all of their "slots" being statically typed. It does seem ironic that where those static languages have been trying to move toward being more dynamic, Pharo newbies would find themselves arrived at a language which is trying to make something that was purely dynamic into something more static.
It is *possible* to implement a kind of TypedSlot, but I do not think that this is what people will use Slots for. And for sure there will be no TypeSlot by default in Pharo.
For Slots there are two levels
1) having objects that describe variables instead of strings. This is very powerful already and will allow us to e.g. do watchpoints/breakpoitns in variables very easily
This is already in Pharo3, but Pharo4 enhances the API and provides with the LinkWrapper slot a way to transparently hook into variable access. This will be very powerful.
2) provide a way to declare that a slot is described by a special subclass of Slot. This is what this change is about
This is what we use Slots for are three directions:
1) active slots that announce when the are set. Replacing the whole ValueHolder stuf to some extend. (This is where Slots + their Meta Object Protocol allow one to implement the special variables in Tweak very easily. It is interesting that there, one had to copy the whole compiler and do many, many hacks.
2) Allow optimizing memory representation. E.g. look at Morph. Many flags are needed, but each takes a whole pinter to true of false. So we have MorphExtension. And then on top of that a property dictionary. With Slots, flags (sots that can only store true or false) can be realised very efficiently (31 boolean slots of the hierarchy map to one ivar). With a PropertySlot, one can have values that are used seldomely encoded in a way that they take no space.
3) Slots + Magritte. Magritte now relies of conventions and methods added to the class side. But what it is: meta descriptions for ivars. I think there will be something very powerful in combining Magritte and Slots.
4) Experiments. One way to see Pharo is that it is suppose to be flexible enough to allow experiments to be done fast and easy so we can explore many ideas easily. These experiments will often be just that: experiments. But some of them will be so good that they will turn out to be useful.
My understanding is that specifying a certain Slot-type can save the need to write, i.e., initializing or validating methods. In exchange, the number of concepts inherent in the language that must be learned and remembered is increased. Standard Smalltalk is only about 2 or 3 concepts -- sending messages and assigning pointers. Period. There's something exciting about that because even Grandma can grok 2 or 3 concepts. No other language is so simple.
Slots do not really increase the concepts: they just are meta objects that have the definition of the behaviour of assignment, turning assignment into message sends.
By introducing the implicit behaviors of slots, the number of different conceptual interactions between code and the slots it references increases exponentially with the number of slot-types. I fear trying to explain them to Grandma will have her eyes starting to glazeâ¦
I do not see now an active slot is harder to understand than e.g. a ValueHolder. or a BooleanSlot should be easier to understand than doing all that explicitely?
Marcus
do you mean...? https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayout... On Fri, Jan 16, 2015 at 8:02 PM, Tim Mackinnon <tim@testit.works> wrote:
Maybe it wasnât a blog post - but I definitely recall reading something last year that introduced the idea and showed some sample code (it wasnât a pdf). I thought it was really handy, and wanted to go back a read it in the context of this thread.
Tim
On 15 Jan 2015, at 18:04, Marcus Denker <marcus.denker@inria.fr> wrote:
On 15 Jan 2015, at 13:04, Tim Mackinnon <tim@testit.works> wrote:
Marcus, can you remind us where that Blog post you wrote about using
slots is? A google search of âPharo Smalltalk slotsâ doesnât seem to find it, and I remember it being a great intro to what is possible.
(Itâs worth considering tagging that post better - it should come up
much higher in google search results).
There is no blog post yet⦠I want to actually have it finished, else I would write a post about something not working⦠which would be hard.
Marcus
Tim
On 12 Jan 2015, at 14:59, Marcus Denker <marcus.denker@inria.fr> wrote:
On 11 Jan 2015, at 18:50, Chris Muller <asqueaker@gmail.com> wrote:
It has been a while since I read the paper, but my memory is that Slots lets you define features and/or constraints on inst-var's. For example, assigning default values or restricting the set of valid values.
This would probably be appealing for folks coming from languages like Java or C++, because they're used to all of their "slots" being statically typed. It does seem ironic that where those static languages have been trying to move toward being more dynamic, Pharo newbies would find themselves arrived at a language which is trying to make something that was purely dynamic into something more static.
It is *possible* to implement a kind of TypedSlot, but I do not think
that
this is what people will use Slots for. And for sure there will be no TypeSlot by default in Pharo.
For Slots there are two levels
1) having objects that describe variables instead of strings. This is very powerful already and will allow us to e.g. do watchpoints/breakpoitns in variables very easily
This is already in Pharo3, but Pharo4 enhances the API and provides with the LinkWrapper slot a way to transparently hook into variable access. This will be very powerful.
2) provide a way to declare that a slot is described by a special subclass of Slot. This is what this change is about
This is what we use Slots for are three directions:
1) active slots that announce when the are set. Replacing the whole ValueHolder stuf to some extend. (This is where Slots + their Meta Object Protocol allow one to implement the special variables in Tweak very easily. It is interesting that there, one had to copy the whole compiler and do many, many hacks.
2) Allow optimizing memory representation. E.g. look at Morph. Many flags are needed, but each takes a whole pinter to true of false. So we have MorphExtension. And then on top of that a property dictionary. With Slots, flags (sots that can only store true or false) can be realised very efficiently (31 boolean slots of the hierarchy map to one ivar). With a PropertySlot, one can have values that are used seldomely encoded in a way that they take no space.
3) Slots + Magritte. Magritte now relies of conventions and methods added to the class side. But what it is: meta descriptions for ivars. I think there will be something very powerful in combining Magritte and Slots.
4) Experiments. One way to see Pharo is that it is suppose to be flexible enough to allow experiments to be done fast and easy so we can explore many ideas easily. These experiments will often be just that: experiments. But some of them will be so good that they will turn out to be useful.
My understanding is that specifying a certain Slot-type can save the need to write, i.e., initializing or validating methods. In exchange, the number of concepts inherent in the language that must be learned and remembered is increased. Standard Smalltalk is only about 2 or 3 concepts -- sending messages and assigning pointers. Period. There's something exciting about that because even Grandma can grok 2 or 3 concepts. No other language is so simple.
Slots do not really increase the concepts: they just are meta objects that have the definition of the behaviour of assignment, turning assignment into message sends.
By introducing the implicit behaviors of slots, the number of different conceptual interactions between code and the slots it references increases exponentially with the number of slot-types. I fear trying to explain them to Grandma will have her eyes starting to glazeâ¦
I do not see now an active slot is harder to understand than e.g. a ValueHolder. or a BooleanSlot should be easier to understand than doing all that explicitely?
Marcus
On 16 Jan 2015, at 11:44, Ben Coman <btc@openInWorld.com> wrote:
do you mean...? https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayout... <https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayout...>
No, Tims refers to the mails I send⦠describing the reflective reading and writing if Slots. My probkem is that I could now dig that out and postpone other things. But I will not. i will write a tutorial later, but not now. (I am already behind at least 3 things that people are waiting for that have higher priorityâ¦) Marcus
Marcus I like your new year resolution... Saying no :) Le 16/1/15 15:51, Marcus Denker a écrit :
On 16 Jan 2015, at 11:44, Ben Coman <btc@openInWorld.com <mailto:btc@openInWorld.com>> wrote:
do you mean...? https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayout...
No, Tims refers to the mails I send⦠describing the reflective reading and writing if Slots.
My probkem is that I could now dig that out and postpone other things. But I will not. i will write a tutorial later, but not now. (I am already behind at least 3 things that people are waiting for that have higher priorityâ¦)
Marcus
On 09 Jan 2015, at 16:15, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
After some searching for a solution⦠that does not break backward-compatibility, I found a way to save classes that use slots.
- if a class just uses ivar Slots, it saves it 100% backward compatible (e.g. loadable in other systems) - if a class uses a special slot or class var, it saves the definition of the slot as the variable name in the monticello model. - on load it checks if there is a space in a variable name, and if yes â> decode these as Slot/Global var definions. - the code path for non-Slot classes stays largely untouched.
This is not beautiful but backward compatible⦠you can even load classes with Slots in Pharo3, it then creates invalid ivar names, which of course means the code does not run but it is readable.
e.g. create a class like
Object subclass: #A slots: { #iv => TestSlot } classVariables: { } category: 'Playgroundâ
(TestSlot is a slot that does not use up space in the instance and instead saves the state in the Slot object, which means all instances share the state. Just a small example)
Limitations -> no support for class variables yet -> class instance variables not yet done, either
Class Instance Slots are now done: https://pharo.fogbugz.com/f/cases/14720 - With this slice - class definition template for metaclass shows slots when enables - Metacello loading implemented for class slots next: Class Variables: add Monticello loading support for class variable definitions. Marcus
On 12 Jan 2015, at 16:20, Marcus Denker <marcus.denker@inria.fr> wrote:
Limitations -> no support for class variables yet -> class instance variables not yet done, either
Class Instance Slots are now done: https://pharo.fogbugz.com/f/cases/14720
- With this slice - class definition template for metaclass shows slots when enables - Metacello loading implemented for class slots
next: Class Variables: add Monticello loading support for class variable definitions.
This is now done: https://pharo.fogbugz.com/f/cases/14726/Add-support-for-loading-special-Clas... <https://pharo.fogbugz.com/f/cases/14726/Add-support-for-loading-special-Clas...> Marcus
On 13 Jan 2015, at 11:57, Marcus Denker <marcus.denker@inria.fr> wrote:
On 12 Jan 2015, at 16:20, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Limitations -> no support for class variables yet -> class instance variables not yet done, either
Class Instance Slots are now done: https://pharo.fogbugz.com/f/cases/14720 <https://pharo.fogbugz.com/f/cases/14720>
- With this slice - class definition template for metaclass shows slots when enables - Metacello loading implemented for class slots
next: Class Variables: add Monticello loading support for class variable definitions.
This is now done:
https://pharo.fogbugz.com/f/cases/14726/Add-support-for-loading-special-Clas... <https://pharo.fogbugz.com/f/cases/14726/Add-support-for-loading-special-Clas...>
This is now in 4.0 update 444 Marcus
On 14 Jan 2015, at 15:57, Marcus Denker <marcus.denker@inria.fr> wrote:
On 13 Jan 2015, at 11:57, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 12 Jan 2015, at 16:20, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Limitations -> no support for class variables yet -> class instance variables not yet done, either
Class Instance Slots are now done: https://pharo.fogbugz.com/f/cases/14720 <https://pharo.fogbugz.com/f/cases/14720>
- With this slice - class definition template for metaclass shows slots when enables - Metacello loading implemented for class slots
next: Class Variables: add Monticello loading support for class variable definitions.
This is now done:
https://pharo.fogbugz.com/f/cases/14726/Add-support-for-loading-special-Clas... <https://pharo.fogbugz.com/f/cases/14726/Add-support-for-loading-special-Clas...>
This is now in 4.0 update 444
Nope⦠something went wrongâ¦. Marcus
On 14 Jan 2015, at 16:56, Marcus Denker <marcus.denker@inria.fr> wrote:
On 14 Jan 2015, at 15:57, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 13 Jan 2015, at 11:57, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 12 Jan 2015, at 16:20, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Limitations -> no support for class variables yet -> class instance variables not yet done, either
Class Instance Slots are now done: https://pharo.fogbugz.com/f/cases/14720 <https://pharo.fogbugz.com/f/cases/14720>
- With this slice - class definition template for metaclass shows slots when enables - Metacello loading implemented for class slots
next: Class Variables: add Monticello loading support for class variable definitions.
This is now done:
https://pharo.fogbugz.com/f/cases/14726/Add-support-for-loading-special-Clas... <https://pharo.fogbugz.com/f/cases/14726/Add-support-for-loading-special-Clas...>
This is now in 4.0 update 444
Nope⦠something went wrongâ¦.
Finally this is in 4.0 447 Marcus
This is wonderful news, Marcus! Thanks for the hard, tedious (and too often overlooked) work, Doru On Fri, Jan 9, 2015 at 8:15 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
After some searching for a solution⦠that does not break backward-compatibility, I found a way to save classes that use slots.
- if a class just uses ivar Slots, it saves it 100% backward compatible (e.g. loadable in other systems) - if a class uses a special slot or class var, it saves the definition of the slot as the variable name in the monticello model. - on load it checks if there is a space in a variable name, and if yes â> decode these as Slot/Global var definions. - the code path for non-Slot classes stays largely untouched.
This is not beautiful but backward compatible⦠you can even load classes with Slots in Pharo3, it then creates invalid ivar names, which of course means the code does not run but it is readable.
e.g. create a class like
Object subclass: #A slots: { #iv => TestSlot } classVariables: { } category: 'Playgroundâ
(TestSlot is a slot that does not use up space in the instance and instead saves the state in the Slot object, which means all instances share the state. Just a small example)
Limitations -> no support for class variables yet -> class instance variables not yet done, either -> nut used much, for sure there will be bugs
This is in 4.0 438
Marcus
-- www.tudorgirba.com "Every thing has its own flow"
+1 Le 12/1/15 21:21, Tudor Girba a écrit :
This is wonderful news, Marcus!
Thanks for the hard, tedious (and too often overlooked) work, Doru
On Fri, Jan 9, 2015 at 8:15 PM, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Hi,
After some searching for a solution⦠that does not break backward-compatibility, I found a way to save classes that use slots.
- if a class just uses ivar Slots, it saves it 100% backward compatible (e.g. loadable in other systems) - if a class uses a special slot or class var, it saves the definition of the slot as the variable name in the monticello model. - on load it checks if there is a space in a variable name, and if yes â> decode these as Slot/Global var definions. - the code path for non-Slot classes stays largely untouched.
This is not beautiful but backward compatible⦠you can even load classes with Slots in Pharo3, it then creates invalid ivar names, which of course means the code does not run but it is readable.
e.g. create a class like
Object subclass: #A slots: { #iv => TestSlot } classVariables: { } category: 'Playgroundâ
(TestSlot is a slot that does not use up space in the instance and instead saves the state in the Slot object, which means all instances share the state. Just a small example)
Limitations -> no support for class variables yet -> class instance variables not yet done, either -> nut used much, for sure there will be bugs
This is in 4.0 438
Marcus
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
participants (8)
-
Ben Coman -
Chris Muller -
Eliot Miranda -
Marcus Denker -
stepharo -
Tim Mackinnon -
Torsten Bergmann -
Tudor Girba