@Chris, That sounds like a balance response. Its also been a while since I read it, and probably time I read it again and to have a play with slots (although last I heard it wasn't ready for prime time to do everything in the paper.) While the cognitive load might go up, I don't think its necessarily exponential. They way I think about it (blurred since I last read the paper) is that the assignment operator sort-of becomes a message send that you can redefine, and the slots are like mini-classes with limited scope - so there is a reuse of concepts. The complexity for grandma will all come down to the discoverability build into the tools - like how debugging interacts with slots. I don't think (and hope) it won't be much harder than learning to work with both an instance & class-side, and the difference between instance, class, class-instance and pool variables.
On Mon, Jan 12, 2015 at 5:50 AM, 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. > > 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. > > 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... > > PS -- I hope no one would characterize me as "violently" against > slots. It may simply be my own ignorance.. > > On Fri, Jan 9, 2015 at 1:50 PM, Eliot Miranda <eliot.mira...@gmail.com> > wrote: > > > > > > On Fri, Jan 9, 2015 at 11:47 AM, Marcus Denker <marcus.den...@inria.fr> > > wrote: > >> > >> > >> > On 09 Jan 2015, at 16:45, Eliot Miranda <eliot.mira...@gmail.com> > wrote: > >> > > >> > Hi Marcus, > >> > > >> > > >> > P.S. Maybe now Slots are ready for stealing by Squeak ;-) > >> > >> Everything I ever did for Pharo I wanted to do for Squeak… but I could > not > >> because > >> someone was violently against it. > > > > > > We will heal. It may take a long time, but we will. And things are > going > > great right now, especially for Pharo. So I hope that your pain will > ease > > and that one day you will be free of it. Hugs, and happy new year. And > > thanks for Slots and Opal and all the other wonderful things you do. > > > >> Marcus > >> > >> > > > > > > > > -- > > best, > > Eliot > >
