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