<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? 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. Also, sometimes the collection *is* the element (i.e. Vector*) as far as most code is concerned.<div><br></div><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. 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><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 30, 2019 at 7:49 AM Juan Vuletich <<a 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"><u></u>
<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 href="http://www.cuis-smalltalk.org" target="_blank">www.cuis-smalltalk.org</a>
<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a href="https://github.com/jvuletich" target="_blank">https://github.com/jvuletich</a>
<a 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 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 href="http://www.cuis-smalltalk.org" rel="noreferrer" target="_blank">www.cuis-smalltalk.org</a><br>
<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a><br>
<a href="https://github.com/jvuletich" rel="noreferrer" target="_blank">https://github.com/jvuletich</a><br>
<a 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 href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a 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>