FYI:

SmallScript has array-slice is built into the language as a user
definable message form. It also supports interior pointers to allow one
objects structure to refer to some aspect of another objects structure.

In SmallScript you can just write:

Eval [
	|a| := {6,5,4,3,2,1,0}.

	"" whatever you want here

	"" later pull out a slice
	|s| := a[2:4].

	"" update a slice
	a[3:5] := 9.
]

You can directly define your own array-slice methods on any class, for
any purpose, scoped to any namespace, you desire. 

This includes creating multi-dimensional arrays, etc. 

By default, using the intrinsic message aliasing services, the
#[<>:<>]() array-slice form is mapped to copyFrom:to:.

Method [
[a:b]()
	"slice body here"
]

Method [
[a:b](setValue)
	"slice body here"
]

Method [
[dim1][dim2][dim3A:dim3B]()
	"slice body here"
]

Method [
[dim1][dim2][dim3A:dim3B](setValue)
	"slice body here"
]

You can combine this with var-arg mechanism to provide arbitrary
indices, etc. Which enables you to write one method and have it handle
many cases.

SmallScript also supports optional typing, multimethods, and value-type
structs allowing you to create real typed c-struct arrays like arrays of
floats, etc.

Class name: Foo fields: struct Float64 m[10].
Eval [
	|f| := Foo new.
	f.m[2:7] := Float.pi.
]

-- Dave S. [SmallScript Corp]

SmallScript for the AOS & .NET Platforms
David.Simmons at SmallScript.com | http://www.smallscript.org


> -----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: Monday, July 08, 2002 8:39 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: objectification (was: Jython vs Squeak for teaching
multimedia)
> 
> On Friday 05 July 2002 13:27, Alan Kay wrote:
> >       On this list, I've mentioned several times that variables and
> > instances should be objectified. This has been done in several other
> > systems to provide much better leverage on a number of important
> > problems.
> 
> I don't know what you mean by objectified instances, but had an
> interesting idea on how to deal with variables. I borrowed the term
> "slices" from ZX81 Basic, but the inspiration was mostly from APL.
> 
> A slice would be related to a part of an object (or a parts of several
> objects) in a similar way that a stream is related to its collection.
> So if I create
> 
>      s := ArraySlice on: #(6 5 4 3 2 1 0) from: 2 to: 4
> 
> then I could do something like
> 
>             s put: 9
> 
> and have #(6 9 9 9 2 1 0) as a result. This might also be interesting
> 
>          v := VariableSlice on: 7 at 8 named: #y
> 
> And we should be able to combine slices in various neat ways. The
> original idea was more as a GUI level device and David Ungar has
> recently partly implemented this in Self. There is a little more about
> slices at http://www.lsi.usp.br/~jecel/tech.html
> 
> >       Messages and message sending could be more objectified. This
> > would allow a much more flexible approach to trying delegation
> > schemes, finding alternatives to inheritance, etc.
> >       Another larger area that I'm astounded that no grad student
has
> > done a thesis on, would be to take the "Smalltalk VM in itself" that
> > we use for bootstrapping, and make it into a real OOP model itself.
A
> > large part of this is just to restructure the messy workable thing
we
> > have now.
> 
> My Ecoop95 paper (http://www.lsi.usp.br/~jecel/jabs7.html with a later
> version published as a chapter in a book) was exactly about this. If
> you find that grad student in the next few months, have him (is it
ever
> a "her" in this field?) talk to me.
> 
> >      Methods could stand to be more objectified. I'd like to see
> > methods that have a vertical bar down the middle. On the left would
> > be the "reference code": the simplest code that does what the method
> > should do. On the right would be the "pragmatic code": a bunch of
> > cases for running the meaning efficiently. You should be able to run
> > both sides when debugging, etc.
> 
> One big difference between the reference code and the pragmatic code
is
> the cacheing of results. Up to a certain point it would be possible to
> transform the former into the latter by adding annotations for a
"cache
> manager". I have more details about this in the same page that talks
> about slices.
> 
> >      Another method objectification would be to have many
polymorphic
> > methods be instances of a class that guards the meaning of the
> > polymorphism. This is part of having a model for both variables and
> > "slots", etc.
> 
> In the CoDA reflective Smalltalk system, this would be handled by
> replacing an object's default Protocol meta-object.
> 
> >       One way to play with this would be to just take the three
> > "principles" above and make a complete model. This is pretty easy.
> > The important thing that CLOS (e.g.) did was to make the additions
to
> > the models compilable so that metachanges could be as efficient as
> > the kernel. We kind of have this with SLANG, but the whole apparatus
> > could be much much cleaner.
> 
> A Jitter in Smalltalk would do the job.
> 
> -- Jecel