[Cuis-dev] [Ann] Serialization of BlockClosures

[Juan Vuletich]

(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 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



> On Mon, Sep 30, 2019 at 7:49 AM Juan Vuletich <juan at jvuletich.org 
> <mailto: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 Vuletich
>     www.cuis-smalltalk.org  <http://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
>
>
>     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 <mailto: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 <http://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 <mailto: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/fe8bb574/attachment.htm>