<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
(inline)<br>
<br>
On 9/30/2019 4:46 PM, Phil B wrote:
<blockquote
cite="mid:CAMJMOej6OgMgsUQG_5Q=pQRCkf7HQ5yjzYPjEVi6cScTLNrUZQ@mail.gmail.com"
type="cite">
<div dir="ltr">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? </div>
</blockquote>
<br>
No, this is not what I tried to do. 'Color red species = FloatArray'.<br>
<br>
<blockquote
cite="mid:CAMJMOej6OgMgsUQG_5Q=pQRCkf7HQ5yjzYPjEVi6cScTLNrUZQ@mail.gmail.com"
type="cite">
<div dir="ltr">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. </div>
</blockquote>
<br>
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 ]'.<br>
<br>
Does this reasoning apply to the examples you are seeing?<br>
<br>
<blockquote
cite="mid:CAMJMOej6OgMgsUQG_5Q=pQRCkf7HQ5yjzYPjEVi6cScTLNrUZQ@mail.gmail.com"
type="cite">
<div dir="ltr">Also, sometimes the collection *is* the element
(i.e. Vector*) as far as most code is concerned.</div>
</blockquote>
<br>
Not sure how this relates to what #species answers... Maybe
elaborate a bit on this.<br>
<br>
<blockquote
cite="mid:CAMJMOej6OgMgsUQG_5Q=pQRCkf7HQ5yjzYPjEVi6cScTLNrUZQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>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. <br>
</div>
</div>
</blockquote>
<br>
Exactly. Besides, any collection class is free to redefine #species
appropriately.<br>
<br>
<blockquote
cite="mid:CAMJMOej6OgMgsUQG_5Q=pQRCkf7HQ5yjzYPjEVi6cScTLNrUZQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div> 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.)</div>
</div>
</blockquote>
<br>
It should always be a collection class, that is appropriate as a
result.<br>
<br>
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 #=.<br>
<br>
Thanks,<br>
<pre class="moz-signature" cols="72">--
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a>
<a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a>
<a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
<br>
<br>
<blockquote
cite="mid:CAMJMOej6OgMgsUQG_5Q=pQRCkf7HQ5yjzYPjEVi6cScTLNrUZQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Sep 30, 2019 at 7:49
AM Juan Vuletich <<a moz-do-not-send="true"
href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff"> <br>
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.<br>
<br>
The idea is to fix things like<br>
<br>
Color red select: [ :v | v > 0.5 ]<br>
<br>
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?<br>
<br>
Thanks,<br>
<pre cols="72">--
Juan Vuletich
<a moz-do-not-send="true" href="http://www.cuis-smalltalk.org" target="_blank">www.cuis-smalltalk.org</a>
<a moz-do-not-send="true" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a moz-do-not-send="true" href="https://github.com/jvuletich" target="_blank">https://github.com/jvuletich</a>
<a moz-do-not-send="true" href="https://www.linkedin.com/in/juan-vuletich-75611b3" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
<br>
On 9/30/2019 7:29 AM, Phil B wrote:
<blockquote type="cite">
<div dir="ltr">Juan,
<div><br>
</div>
<div>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)</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Phil</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Sep 29, 2019
at 1:57 PM Juan Vuletich via Cuis-dev <<a
moz-do-not-send="true"
href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin: 0px 0px
0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">Hi Folks,<br>
<br>
After many requests made during a long time, it is
finally here. We can <br>
now serialize almost any BlockClosures, including
those that use outer <br>
temps, self, instance variables, etc.<br>
<br>
The only closures that can't be serialized are those
that do non-local <br>
returns (^stuff) or super sends. These are usually not
passed around or <br>
stored in variables, so I don't expect this to be a
limitation.<br>
<br>
Updates now at GitHub.<br>
<br>
Cheers,<br>
<br>
-- <br>
Juan Vuletich<br>
<a moz-do-not-send="true"
href="http://www.cuis-smalltalk.org"
rel="noreferrer" target="_blank">www.cuis-smalltalk.org</a><br>
<a moz-do-not-send="true"
href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev"
rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a><br>
<a moz-do-not-send="true"
href="https://github.com/jvuletich" rel="noreferrer"
target="_blank">https://github.com/jvuletich</a><br>
<a moz-do-not-send="true"
href="https://www.linkedin.com/in/juan-vuletich-75611b3"
rel="noreferrer" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a><br>
@JuanVuletich<br>
<br>
-- <br>
Cuis-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a moz-do-not-send="true"
href="https://lists.cuis.st/mailman/listinfo/cuis-dev"
rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>