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