[Cuis-dev] [Ann] Serialization of BlockClosures

[Phil B]

Juan,

On Mon, Sep 30, 2019 at 4:51 PM Juan Vuletich <juan at jvuletich.org> wrote:

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

But you're doing it so that you can return one or more *elements* of a
Color as you indicate below...


>
> 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 ]'.
>

Right, you want to perform an operation returning one or more of its
elements rather than a (new/existing) Color.  Unless I'm missing something,
you're not really interested in the type of the 'containing' object but
rather it's elements.  I'm not arguing that there's anything wrong with
wanting to take this view, but it does seem inconsistent with how #species
is defined and generally used elsewhere.


>
> Does this reasoning apply to the examples you are seeing?
>

No, the typical use case I am seeing would be (using Color as an example)
to create a new instance of a Color without assuming that the class of the
object being passed in is the class to use to create a new instance.  The
two main cases in my code seem to be:

1) You have polymorphic subtypes where the subtypes have #species return
the parent type.  The parent class then decides which subclass to actually
use at instantiation time based on the parameters provided.

2) You have a specialized subtype that you generally don't want (or can't
be) instantiated as an instance of self class, but rather a more generic
supertype.


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

The shortest way I can explain it is to point to the comment in
Object>species.  When you want to recreate a Color, you want the class
Color used, not FloatArray.


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

That's my argument: I don't think your override for ArrayedCollection
fits... it's a different kind of use case you're defining.


>
> 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 #=.
>

Yep, that's what I was suggesting but not with the most accurate name.  How
about something like #elementContainerSpecies? (I *think* this would only
apply to the ArrayedCollection hierarchy rather than something higher up,
right?)


> Thanks,
>
> --
> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
>
Thanks,
Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190930/5bc0ca73/attachment-0001.htm>