slices (was: objectification)
Jecel Assumpcao Jr
jecel at merlintec.com
Wed Jul 10 21:08:53 UTC 2002
On Wednesday 10 July 2002 04:51, David Simmons wrote:
> 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?
No.... wait... ok, the @ thing is exactly what I was talking about. I
might want to send a message to all elements of a slice (color: 'blue',
for example) and F-script can do this and far more.
One difference between my idea for slices and what they did is that I
wanted to keep track of an object's origin like this
a := #(1 2 3 4).
b := #(5 6 7 8).
|s| := a[2:3],b[2:3]. "concatenation of two slices"
s := 9. "now a is #(1 9 9 4) and b is #(5 9 9 8)"
Perhaps this is overkill?
> b) Python (or) Ruby slices?
> ===
Nope.... ok, Python looks like Lua in this regard.... Ruby's slice! to
delete things is interesting. A little better than ZX81 Basic, of
course, but F-Script is more like what I was looking for.
> 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.
Yes, this is what you showed in your previous 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.
Ok, lot's of people hate #value:value:value: as well ;-)
> 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.
Great!
> 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.
This was what I meant by "objectified". Since you only defined methods
but not classes in your previous examples I thought you didn't have
this capability.
> 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.
There are some people trying to build prototype based language (slightly
inspired on Cecil) with this as their central concept:
http://tunes.org/~eihrul/pmd.pdf
> Class name: ArraySlice extends: IndexedCollection
> {
> ...
> "presume we have written appropriate protocol"
> }
>
> Method behavior: IndexedCollection [
> [a:b]()
> ^ArraySlice on: self start: a end: b
> ]
Right, if you can define a method for the notation there is no reason
why the method can't create and return a new object. Certainly if my
idea was possible in regular Smalltalk it would be even simpler in
SmallScript. I simply didn't think that this was the style you wanted.
> Method behavior: IndexedCollection [<'cloning'>
> [<ArraySlice>slice]()
> ^ArraySlice on: self start: slice.start end: slice.end
> ]
Eh? Ok, this makes sense unless you come from an APL (or F-script, it
seems) background. In that case you might want instead
^ArraySlice on: self withIndexes: slice elements
> Eval [
>
> |slice| := {3,4,5}[2:3].
> |
> |slice2| := someCollection[slice].
>
> "or equivalently, since #::[<>]() is aliased to #at:"
> slice2 := someCollection at: slice.
> ]
This would be the same as someCollection[2:3], right? My idea would
result in someCollection[4,5]. I am not sure which is less confusing.
> Does this cover the "objectification" were you looking for?
>
> Making slice facilities useful in SmallScript is important.
> Understanding what you are looking for helps.
By defining classes you can certainly do all that I imagined. The slice
objects can also act as proxies and resend messages to all their
elements, which is one thing that I want to do a lot.
My interest is exposing this at the GUI level. So slices certainly must
be an object if they are to have a visual representation. Then you can
create a slice on all even numbered headers in a text and then send the
message #bold to them. Oh, I know that the "right" way to do this is to
structure the objects so there would be one style object representing
all even numbered headers and then we could send #bold to it. But in
practice no matter how we organize things we will need to talk about
collections of things that don't fit into our plans. So I want slices.
> P.S., SmallScript's selector namespace modularization allows more
> than one slice system to coexist transparently in a single running
> program/image.
I just looked at the squeak modules list archive and it seems that this
kind of thing will have to be solved here as well.
-- Jecel
More information about the Squeak-dev
mailing list
|