Hey, brilliant explanation, thanks.  I respect _this_ argument and,
for the sake of moving on, will retract my proposal (sorry Brent!).
But please consider my final thoughts that address your explanation,
and I will now shut up..  :)

_Semantically_, I think it's reasonable to expect that, for most any
kind of "Object", whether it's a musical-note or a coffee-mug, if you
can have one of them, you can always consider the possibility of two
or more.  Yes, there are singletons, but a 98% case is worth a
generalization in Object.

I do have three such cases across my various applications (in separate
class-hierarchies), so it made sense for me to "factor" this concept
into their common superclass, Object,

Object>>, aCollection
    ^ self asCollection, aCollection asCollection

rather than duplicated three times.

Now, notice how only the _abstract portion_ of our common "pattern"
(as you rightly called it) is in Object.  This implementation provides
the general behavior needed for muO and all three of my apps (as well
as String and SequentialSound, etc.) to express a list of their
primary domain objects.  Instead of muO implementing #, (comma) it
would just implement #asCollection:

  MusicalPhrase>>#asCollection
     ^ self

  MusicalNote>>#asCollection
    ^ MusicalPhrase with: self

I probably should have tried to sell this angle to you earlier, but
Object>>#, is not much code for me to duplicate.  And, while we
obviously agree that comma #, is a beautiful way to express a list,
developers don't need it and the need for direct Smalltalk
interpretation of _user_ input is probably rare..  OK!

(But I need to still consider Object>>#asCollection though, so I don't
have to duplicate THAT in all three places too..)

Good debate, thanks Stef.

 - Chris



2010/9/24 Stéphane Rollandin <lecteur at zogotounga.net>:
> Let me illustrate my previous post with what I did in MuO.
>
> MuO is a framework for music composition. Any MusicalElement represent some
> sort of musical data in a temporal framework.
>
> Two MusicalElement instances can always be mixed; the resulting mix is
> always a MusicalElement.
>
> Here enters the concatenation/collection making ambiguity.
>
> If a is a MusicalNote, and b another MusicalNote, then
>
>        a,b
>
> is a MusicalPhrase.
>
> While if a and b are musicalPhrase, then
>
>        a,b
>
> is also a MusicalPhrase.
>
> This is in the line of Chris' proposal (which I am opposed to); the reason I
> find it meaningful here is that both MusicalNote and MusicalPhrase are
> subclasses of MusicalElement.
>
> In the context of what a MusicalElement is, it makes sense that
> concatenation of two objects leads to an object of a different class,
> similar to a collection, because both the initial objects and the collection
> are assured to mix freely via the MusicalElement protocol.
>
> In the general case though, there is no reason that the protocol (taken in
> the broadest sense, as "expected usage") applying to object also applies to
> a collection of objects. Indeed, a collection of object is generally
> ignorant of the nature of its elements. String is an exception and, guess
> what, String does generalize concatenation to non-String objects.
>
> Similarly, AbstractSound implements #, in a way close to Chris' proposal,
> since if a and b are sounds then a,b is a SequentialSound (the analog of
> collection in that case). But note that SequentialSound in an AbstractSound.
>
> So I think we have a pattern here: Chris' proposal make sense to me when it
> operates in a delimited domain where it is clear why we can consider
> anObject to also represent {anObject}. Such a domain implicitely states that
> its objects all have a structural property of potential multiplicity that
> makes it logical that the simplest of these objects can be considered as
> composed of themselves alone.
>
> So a Character is a sort of singleton String, seen from the point of view of
> String. Similarly, an AbstractSound is a singleton SequentialSound, while a
> MusicalNote is a singleton MusicalPhrase, as seen by MusicalElement.
>
> In this way of looking to the problem, Chris's proposal makes the point of
> view of Array important enough that any Object can be seen as an Array
> singleton.
>
> That's where I disagree, for at least two reasons:
> - philosophically, I don't think Array is so central in Smalltalk that we
> have to look to every object through its eyes
> - practically, we have a rich set of Collections, so why pick up Array other
> IdentitySet or SequenceableCollection ?
>
>
> sorry for the long post, hope it was clear...
>
> Stef
>
>
>
>
>
>