[Cuis-dev] [Ann] Serialization of BlockClosures

[Nicolas Cellier]

Hi Juan,
Something strikes me.
Isn't this example a pathological case of inheritance? Is Color really kind
of Collection? Wouldn't any object potentially be a collection of its
instances variables in this case?

Le lun. 30 sept. 2019 à 22:51, Juan Vuletich via Cuis-dev <
cuis-dev at lists.cuis.st> a écrit :

> (inline)
>
> On 9/30/2019 4:46 PM, Phil B wrote:
>
> 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?
>
>
> No, this is not what I tried to do. 'Color red species = FloatArray'.
>
> 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.
>
>
> That is exactly what I tried to do. For instance, Color is a suclass of
> FloatArray, that adds the restriction that it must have 3 elements.
> TranslucentColor is similar, but must be of size = 4. If you do a #select:
> on them, the answer could have less than 3 (or 4) elements, and then, the
> correct class for the answer is FloatArray and not Color. See what happens
> with 'Color red select: [ :v | v > 0.5 ]'.
>
> Does this reasoning apply to the examples you are seeing?
>
> Also, sometimes the collection *is* the element (i.e. Vector*) as far as
> most code is concerned.
>
>
> Not sure how this relates to what #species answers... Maybe elaborate a
> bit on this.
>
> 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.
>
>
> Exactly. Besides, any collection class is free to redefine #species
> appropriately.
>
> 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.)
>
>
> It should always be a collection class, that is appropriate as a result.
>
> The problem I do see is that, perhaps, 'Color red collect: [ :v | v / 2 ]'
> could answer an instance of Color. So maybe  we could make the search for
> an appropriate superclass in a separate message, like
> #speciesForPotentiallyShorterResult (uhg that's ugly), and only call this
> other method from #select:, but not from #collect: or #=.
>
> 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 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
>>>
>>
>>
> --
> 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/20191001/d79a3e3d/attachment.htm>