[Cuis-dev] [Ann] Serialization of BlockClosures

[Phil B]

Juan,

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

> Please, let's restart this discussion with a different focus. Let's
> forget for a while about #species, that is a private message, and lets
> focus on external behavior. Let's go to #species or an alternative
> implementation strategy afterwards. Also, please let's use examples.
>

Well, um, err... you're kind of taking my main objection out of the scope
of discussion.  If you don't redefine #species I'm sort of OK with what you
want (i.e. I probably won't use it for the reasons cited in my response in
Nicolas' thread[1], but I won't try to stand in the way of you adding the
functionality you want)


> Take a fresh image. Evaluate:
>
> Color red select: [ :v | v > 0.5 ].
>
> Color red collect: [ :v | v printString ].
>
> Both fail. #select: fails because it might answer less than 3 elements,
> and a Color must have 3 elements. #collect: fails because the answer
> elements might be of any class, but Color components must be Float.
>

Yep.  Another solution would be to override #select: etc. for Color with
'self error: 'Not a collection!''  OK, I'm not serious about all those
overrides, but my point (per my response in the other thread) is that
externally we shouldn't be depending on Color to be a collection.


>
> Possible solutions might be answering FloatArray (fixes #select: but not
> #collect:) or Array (fixes both). Changesets #3889 and #3890 attempt to
> fix #select: by looking for some superclass that doesn't enforce a
> specific number of elements, in #species. In this implementation, the
> answer of #species only changes for classes that do enforce a specific
> number of elements.
>

> As another example of the #collect: problem, see
>
>
> 'Hello' collect: [ :c | c numericValue ]
>
> String chooses to reimplement #collect: . A more general solution would
> be desirable.
>

String is a good example of another class where it's collection-ness has
been even more abused, IMO.[2]  I would much rather have code that need it,
however redundant, do something along the lines of 'somestring'
asCharacters.  That would make it perfectly clear when you need to pierce
it's String-ness and treat it as a sequence of characters.  I expect most
Smalltalkers would hate this idea.


>
> Please provide other actual examples that I can try in a Cuis image
> where the assumptions made for Color become invalid, and your code
> breaks. Or provide examples I can try of how you use #species, and your
> code breaks with #3889 and #3890. I really want to understand the
> problems you see, and I find it very difficult with only an abstract
> description.
>

The first example I ran into was in Vector3>cross: (you can see an
implementation of it here:
https://github.com/pbella/Cuis-OpenGL/blob/master/3DTransform.pck.st#L2247)
though pretty much any sender of #species (I have over 200 in my image)
potentially applies: what you're returning changes the definition of
#species and therefore may[3] break existing code.  What's most problematic
about this change is that because it's relatively subtle, it may not be
immediately obvious in all cases what the breakage is because existing code
will kinda-sorta work: you'll get back a class which may mostly work right
up until the point that it doesn't which might be pretty far from the
sender of #species that resulted in the now problematic instance.


> Thanks,
>
> --
> Juan Vuletich
>

Thanks,
Phil

[1] It's not an abstract objection: I actually have Color-compatible
implementations that aren't in the Collection hierarchy that I want to keep
interchangeable at an instance level.

[2] This also isn't an abstract objection.  I have lots of object-walking
code that I have to specifically say 'enumerate (or whatever) this
collection only if it's a non-String collection' to avoid all sorts of
issues.  From the standpoint of my code, String is an atomic type that
logically (usually) doesn't make sense to treat as a collection.

[3] Now you may say 'Ha! See... "may" break.. how big a problem can it be
then?'  It means it's among the biggest PITA-type breakage you can have.
It won't always, and won't immediately, break things.  When it does, have
fun tracking it down in your code.  Great, now you've tracked it down... oh
crap, that method now uses ad hoc polymorphism... now what?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191001/0f215852/attachment.htm>