do you mean...? https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayouts.pdf
On Fri, Jan 16, 2015 at 8:02 PM, Tim Mackinnon <[email protected]> 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 <[email protected]> wrote: > > > > >> On 15 Jan 2015, at 13:04, Tim Mackinnon <[email protected]> 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 <[email protected]> wrote: > >> > >>> > >>>> On 11 Jan 2015, at 18:50, Chris Muller <[email protected]> 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 > >>> > >>> > >> > >> > > > > > > >
