[Cuis-dev] [Ann] Serialization of BlockClosures

[Juan Vuletich]

On 10/1/2019 2:39 AM, Phil B wrote:
> Juan,
>
> On Mon, Sep 30, 2019 at 11:24 PM Juan Vuletich <juan at jvuletich.org 
> <mailto: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?
>

I took a look at your code, and it seems to assume that #species is a 
synonym for #class. I'd rather call #class, but that's not the main 
issue here.

The changes I did to #species are not useful, because we need a better 
solution that treats #select: (same class of elements, possibly 
different number of them) and #collect: (possibly different kind of 
elements, but same number of them) in a distinct way.

Besides, I made Color (the motivation for that change) no longer be a 
Collection, as you, Nicolas and Hernán have suggested, and just told in 
a separate email.

So, I removed ArrayedCollection>>#species.

Thanks for caring.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191002/a382ba2a/attachment-0001.htm>