[Cuis-dev] [Ann] Serialization of BlockClosures

Phil B pbpublist at gmail.com
Mon Sep 30 12:46:43 PDT 2019


OK, now I understand what you are going for... this seems like a
convenience optimization in the wrong place.  Wouldn't it make more sense
to have this logic in something like #elementSpecies?  Most of my code that
uses #species with collections is expecting it to return what kind of
collection it should use when creating some sort of collection-based
copy/result, not an individual element.  Also, sometimes the collection
*is* the element (i.e. Vector*) as far as most code is concerned.

Lots of FFI code uses ArrayedCollection subclasses for buffers of various
types and you typically want #species to return the appropriate collection
type (not always of the same class) when doing something with it.  It also
seems a bit weird for ArrayedCollection to sometimes return the class of
its elements while other collections return the class of the collection
itself (which it pretty much has to for heterogeneous collections.)

On Mon, Sep 30, 2019 at 7:49 AM Juan Vuletich <juan at jvuletich.org> wrote:

>
> Oh, apologies. I thought those were harmless and didn't even comment about
> them. You can get by by removing #3889 and #3890 until we understand and
> fix.
>
> The idea is to fix things like
>
> Color red select: [ :v | v > 0.5 ]
>
> This shouldn't answer an instance of Color, but of the closest superclass
> that can have instances of any size. The same happens for many other
> classes in optional packages. How is this affecting your code? I guess you
> have ArrayedCollection classes that answer a non-zero value to
> #numElements, but their #species should be the class, right? What would
> happen if a #select: answers a smaller instance? And more important, what
> else are we using #species for?
>
> Thanks,
>
> --
> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
>
> On 9/30/2019 7:29 AM, Phil B wrote:
>
> Juan,
>
> Could you explain the why behind the ArrayedCollection #species change?  I
> understand what you're doing, but not why... (rather important since my
> subclasses are now breaking and I'm not following the reasoning yet)
>
> Thanks,
> Phil
>
> On Sun, Sep 29, 2019 at 1:57 PM Juan Vuletich via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>> Hi Folks,
>>
>> After many requests made during a long time, it is finally here. We can
>> now serialize almost any BlockClosures, including those that use outer
>> temps, self, instance variables, etc.
>>
>> The only closures that can't be serialized are those that do non-local
>> returns (^stuff) or super sends. These are usually not passed around or
>> stored in variables, so I don't expect this to be a limitation.
>>
>> Updates now at GitHub.
>>
>> Cheers,
>>
>> --
>> Juan Vuletich
>> www.cuis-smalltalk.org
>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>> https://github.com/jvuletich
>> https://www.linkedin.com/in/juan-vuletich-75611b3
>> @JuanVuletich
>>
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190930/4109b5bc/attachment.htm>


More information about the Cuis-dev mailing list