> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of Jecel Assumpcao Jr
> Sent: Tuesday, July 09, 2002 12:35 PM
> To: squeak-dev at 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 at SmallScript.com | http://www.smallscript.org

> 
> Cheers,
> -- Jecel