[Cuis-dev] [Ann] Serialization of BlockClosures

[Phil B]

Juan,

On Wed, Oct 2, 2019 at 8:20 PM Juan Vuletich <juan at jvuletich.org> wrote:

> Additionally, in the Collection hierarchy, #species is used for #select:
> and #collect: as I said before. In the base image, all the classes that
> redefine #species are Collections.
>

That isn't entirely surprising as some types of collections can have
polymorphic hierarchies.  Granted, in the base image only SortedCollection
could be argued (if you squint your eyes) as sort of fitting into that
category but its implementation really doesn't.  Symbol's override could
also be argued as being 'this is about the best you can do for a
naive instantiator' which many senders of #species can be.

In my image collections aren't the only overrides (I have a couple
dozen)... and that's the problem.  I'm quite dependent on it based on what
I understood it to mean.  If my understanding is incorrect, I'll stop using
it and come up with a different mechanism.


> And they redefine it essentially to make #select: and #collect: answer a
> reasonable result, for example for
>
> 'Hello' collect: [ :a | a numericValue ].
>
> (1 to: 20) select: [ :a | a isPrime ].
>

But then you look at many of the senders of #species (including
non-collection) which are also using it for equality tests and
(non-enumeration return) instance creation.  (when I did a search for
source containing ' class new' vs ' species new' (note the leading space)
there were more #species senders)


> In those cases (the only ones where #species and #class differ in the base
> image), the objective is _not_ to recreate the receiver.
>

I'd argue that in those cases the overrides are wrong as well. Although the
OrderedCollection override was for SortedCollection which, as I stated
above, I can kind of see... but it seems like it really should just be on
SortedCollection.

>From my interpretation of the stated intent, and the fact that it's a
rather valuable single word selector, it seems like the focus should be on
recreating the receiver (which is more globally useful) not as a
convenience method for enumerator return types (which only applies to a
branch of the class hierarchy.)  We could have something along the lines of
#enumeratorReturnSpecies (or whatever... I don't care what it's called as
long as it's different) as a helper method for collection enumerators and
not pollute #species with those overrides.

To me #species is a lot like #compilerClass: you shouldn't often need to
override it, but when you need it you really need it.  Just because it's
not heavily used doesn't mean it should be fair game to redefine however
one wants.  If you think I'm the one doing that here, let me know and I'll
stop.



>
> Speaking of "original intent", the comment at Object>>species (no
> timestamp, I guess that comes from Squeak 1.1, or maybe Smalltalk-80,
> definitely not written by me) talks about collections, and literally says
> "Species and class are not always the same. For example, the species of
> Interval is Array.".
>

Fair point: the first line in the comment and the last seem contradictory.
So which one wins? (The 'species and class are not always the same' part is
consistent with the first line, the particular example that follows doesn't
seem to be)


> So it seems that #species tries to be too many different things at once...
>

I would agree with that.  That's why I'm pressing the issue... I'd like us
to at least agree what it means in Cuis and use it consistently.  Having it
mean X except when it doesn't isn't terribly useful.  Having it mean X, Y
or Z (which are mutually exclusive) is even worse.


>
> On 10/2/2019 8:14 PM, Phil B wrote:
>
> I've been doing a bit of poking around the image and perhaps a more
> succinct way of making the point is that in general, the pattern of '<an
> object reference> class <an instance creation selector>' usually works but
> is often incorrect.  For example, cases of:
>
> self class new
>
> are often incorrect and should generally, but not always[1], be:
>
> self species new
>
> I suspect the reason this isn't a problem for most people, most of the
> time is that:
>
> 1) most of the time #species and #class return the same class
>
> 2) people are usually directly using instances of relatively
> straightforward class hierarchies
>
> [1] While I'm sure there are cases, they would be the exception rather
> than the rule.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191002/f4473c1e/attachment.htm>