idea: slices

[Jecel Assumpcao Jr]

Rainer Blome wrote:
> Having this functionality is desirable, absolutely.

This is what I am trying to verify. 
 
> Maybe I missed the point, but isn't a slice just a collection that
> offers a `do: block' method (you said it), why introduce a new
> name? 

It is a collection, but it still needs a name. Just as
Sets, Bags, Lists, etc. are collections but have their
own names. On the other hand, slices are a little like
streams in Smalltalk in that they are an interface for
manipulating some other collection.

> And if so, wouldn't `selection' be a better one?  `A
> selection of objects' sounds more comfortable to me than `A slice
> of objects' (What flavor does it have? ;-).

"Selection" is indeed a better name for this. The
problem is that most GUIs already have selections, so
the users and the programmers might overlook that we
have added something. That is the same reason we use
the word "method" instead of "proceedure" in object
oriented programming, even though this irritates a
lot of people. Using a familiar name sometimes leads
to false assumptions.

Having said that, we can call it selection if you
like.

> How should this work?  Basically, I see two possibilities.
> 
> The first is to require every member of the collection to accept a
> `do: block' message, then it is just a matter of forwarding.  This
> looks elegant, but it is a potential breach of encapsulation.  If I
> were an object, I wouldn't blindly accept and execute any block
> that's passed to me.

Why can't it work as normal collections? Pass each
element of the slice to the block

         block value: thisElement
 
> The other option is to have the collection's `do:' method dissect
> the block into a sequence of message expressions and send that
> sequence to all members.  No breach of encapsulation here.  To
> preserve lexical scoping, though, is not really trivial, at least
> not with Self's current code representation facilities.

You want to do multicast message sending? I consider
slices a higher level replacement for that. I can do
multicasting in Merlin since I have reified message
passing, but I don't want a solution that wouldn't
also work in Self 4.0.

> Another way would be to have the receiver of the block dissect it
> and decide about whether or not to accept it depending on the
> contents.  This is least elegant, the block dissection chore
> would be repeated for each member, so this option doesn't count.
> 
> The choice between the first two evaporates when a block actually /is/
> a sequence of messages with reified `lexical' bindings (selectors
> and contexts).

I think you are complicating something that is
almost trivial.

-- Jecel