[Cuis-dev] [Ann] Serialization of BlockClosures

[Phil B]

It's just an old method/comment that no one seems to want to fix. There's
no reference to #species in the draft ANSI spec.  I like GNU Smalltalk's
comment
https://www.gnu.org/software/smalltalk/manual-base/html_node/Object_002dclass-type-methods.html
(basically nicely says 'good luck with that')  After perusing what few
species references I found out there, confusion/disdain for it seems
common.  I have my answer: I'll stop using it.

'This area is wet.  It has always been wet.  We would have done something
to preventing you from slipping... but it's wet.  A note to anyone passing
by: please do not turn off the water.'

On Thu, Oct 3, 2019 at 7:24 AM Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Phil,
>
> species
> "Answer the preferred class for reconstructing the receiver.  For example,
>     collections create new collections whenever enumeration messages such
> as
>     collect: or select: are invoked.  The new kind of collection is
> determined by
>     the species of the original collection.  Species and class are not
> always the
>     same.  For example, the species of Interval is Array."
>
> On 10/2/2019 10:32 PM, Phil B wrote:
>
> ...
>
> 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.
>
>
> I agree. That very comment is already contradictory. As this very thread
> shows, different people have understood it differently. And given that this
> message seems to be quite old, it might be present in other dialects
> (Squeak derived or not), and in ANSI Smalltalk. I'm not sure there's much
> we can do, besides trying not to break too much code...
>
> --
> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191003/996cb46c/attachment.htm>