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 >>> >>> >> >> > >
