-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev- admin@lists.squeakfoundation.org] On Behalf Of Jecel Assumpcao Jr Sent: Tuesday, July 09, 2002 12:35 PM To: squeak-dev@lists.squeakfoundation.org Subject: slices (was: objectification)
On Tuesday 09 July 2002 04:33, David Simmons wrote:
[lots of neat slice examples in SmallScript]
That's great! It looks far better than what I had proposed, but isn't
as
"objectified". In a scripting environment (what I call a "blueprint system") syntax is a major consideration and you did a really nice
job.
My own interest is in what I call "living systems" (which have persistent, hand crafted objects) and so I don't worry about syntax
too
much - the programming environment can hide a lot of the ugliness.
Ok. You've certainly peeked my curiosity. Let's establish a little common ground for talking slice features in scripting applications here...
a) Are you familiar with the (Smalltalk-style-variant) F-Script [http://www.fscript.org/] on the MacOS?
b) Python (or) Ruby slices? ===
I thought/think that the SmallScript slice form is fully objectified. Although probably presented too little to clarify the point.
For slices to be objectified (to me) means that:
1. The slice operations need to be an ordinary message form. Where the dimensions and parameters can have any designed arity (arg-count) just like keyword-messages. Thus any class can define its own meaning for the slice message.
2. The language allows for var-arg (aka optional-args). So that we can define a generic slice message that is the "default" handler for all higher-arity (higher-arg) forms. But, since it is only a default, we can override it with explicit forms where we want to. This allows us to have just one method handle everything for a given class if we want to.
3. We have mixins/interfaces so we can define all the array-slice message behavior/forms in a single mixin with "concrete" methods that implement all the behavior. This allows us to mixin in that implementation with any class we want to have support array-slice protocol -- without needing to write an methods on that class.
4. We can define new classes at will. So we are free to define an <ArraySlice> class that represents the result of sending a array-slice message to a given class that chooses to construct one and return it.
5. We allow optional typing with multi-method overloading. Which means that we can specialize messages with the "same" name, but writing versions of them which differ "only" in their argument types. Thus we can write array-slice methods that accept other slices, or values, etc.
Class name: ArraySlice extends: IndexedCollection { ... "presume we have written appropriate protocol" }
Method behavior: IndexedCollection [ [a:b]() ^ArraySlice on: self start: a end: b ]
Method behavior: IndexedCollection [<'cloning'> [<ArraySlice>slice]() ^ArraySlice on: self start: slice.start end: slice.end ]
Eval [ |slice| := {3,4,5}[2:3].
|slice2| := someCollection[slice].
"or equivalently, since #::[<>]() is aliased to #at:" slice2 := someCollection at: slice. ] ==================
So, now the question.
Does this cover the "objectification" were you looking for?
Making slice facilities useful in SmallScript is important. Understanding what you are looking for helps.
P.S., SmallScript's selector namespace modularization allows more than one slice system to coexist transparently in a single running program/image.
-- Dave S. [SmallScript Corp]
SmallScript for the AOS & .NET Platforms David.Simmons@SmallScript.com | http://www.smallscript.org
Cheers, -- Jecel