Hi Marcus, On Jan 12, 2015, at 6:59 AM, Marcus Denker <marcus.den...@inria.fr> wrote:
> >> 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. I hope we'll also be able to follow a 5th direction, of allowing one to specify a slice or a trait or a package that just adds an inst var to a class instead of having to provide the whole class definition just to add an inst var. > >> 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 >
