> On 11 Jan 2015, at 18:50, Chris Muller <asquea...@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
