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