<div dir="ltr"><div dir="ltr">Juan,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 2, 2019 at 8:20 PM Juan Vuletich <<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div bgcolor="#ffffff">
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.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#ffffff"> And they redefine it
essentially to make #select: and #collect: answer a reasonable
result, for example for <br>
<br>
'Hello' collect: [ :a | a numericValue ].<br>
<br>
(1 to: 20) select: [ :a | a isPrime ].<br></div></blockquote><div><br></div><div>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)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#ffffff">
<br>
In those cases (the only ones where #species and #class differ in
the base image), the objective is _not_ to recreate the receiver.<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#ffffff">
<br>
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.".</div></blockquote><div><br></div><div>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)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#ffffff"> So it seems that
#species tries to be too many different things at once...<br></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#ffffff">
<br>
On 10/2/2019 8:14 PM, Phil B wrote:
<blockquote type="cite">
<div dir="ltr">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:
<div><br>
</div>
<div>self class new</div>
<div><br>
</div>
<div>are often incorrect and should generally, but not
always[1], be:</div>
<div><br>
</div>
<div>self species new</div>
<div><br>
</div>
<div>I suspect the reason this isn't a problem for most people,
most of the time is that:</div>
<div><br>
</div>
<div>1) most of the time #species and #class return the same
class</div>
<div><br>
</div>
<div>2) people are usually directly using instances of
relatively straightforward class hierarchies</div>
<div><br>
</div>
<div>[1] While I'm sure there are cases, they would be the
exception rather than the rule.</div></div></blockquote>
</div>
</blockquote></div></div>