[Cuis-dev] [Ann] Serialization of BlockClosures
Juan Vuletich
juan at jvuletich.org
Mon Sep 30 20:43:41 PDT 2019
Hi Nicolas,
On 9/30/2019 8:36 PM, Nicolas Cellier via Cuis-dev wrote:
> 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?
It can be considered a space optimization. Just like Squeak's encoding
of RGB in a SmallInteger. Other examples in Cuis packages include
Float32Matrix3x3, Float32Vector3, Float64Matrix?x?, Float64Quaternion,
Float64Vector?, GPSPosition, All these could use ivars, but dont, and
inherit from FloatArray or Float64Array.
This makes sense especially on 64 bit images for objects whose parts can
be 32bit or shorter immediates, and if we build many instances. In this
cases, I think the space saving overwheights the inconvenience of not
having real ivars.
> Le lun. 30 sept. 2019 à 22:51, Juan Vuletich via Cuis-dev
> <cuis-dev at lists.cuis.st <mailto: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 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 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
>>>
>>
>
> --
> 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
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191001/aab23068/attachment-0001.htm>
More information about the Cuis-dev
mailing list