<div dir="ltr"><div dir="ltr">Hi Nicolas,</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I don't buy such a definition of polymorphism, because if it is that<br>
restrictive, then it does not exist at all.<br></blockquote><div><br></div><div>ok. Which definition do you use?</div><div>Could you also elaborate why you see it that restrictive?</div><div><br></div><div>BTW, it is important to see that the definition I use is a relationship between a set of objects and a set of messages. The set of messages does not need to be the whole protocol.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Beside, it seems that the polymorphism problem just moved:<br>
<br>
(Dictionary newWithRoomForMoreThan: 10) at: 10 put: self.<br>
(OrderedCollection newWithRoomForMoreThan: 10) at: 10 put: self.<br></blockquote><div><br></div><div>Not really, OrderedCollection does not answer #newWithRoomForMoreThan: </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Ah, but we can create two different messages as well...<br>
Or maybe at:put: is false polymorphism?<br>
Or isn't it rather Dictionary and OrderedCollection that are not polymorphic?<br></blockquote><div><br></div><div>From my point of view, Dictionary and OrderedCollection are not completely polymorphic, OrderedCollections does not answer #keys, #values, #keysAndValuesDo:, etc.</div><div>As I see it, they are polymorphic regarding other sets of messages, but not all the protocol.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If I follow the same path:<br>
<br>
(Array new: 10) add: 5.<br>
(OrderedCollection new: 10) add: 5.<br>
<br>
#new: is not polymorphic because in one case it answers a collection<br>
that cannot grow, and in the other case it answers a collection that<br>
can grow...<br></blockquote><div><br></div><div>Array and OrderedCollection are not polymorphic regarding the message #add:, no matter how you instantiate those collections.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
OrderedCollection and Array are not polymorphic, </blockquote><div><br></div><div>They are not "completely" polymorphic, but they are regarding certain messages like #select:, #reject:, #detect:, #size, etc.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">they don't behave the<br>
same way, Interval neither, RunArray neither etc...<br>
It's not just a different implementation of the same thing. Otherwise,<br>
no need for so many subclasses.<br>
<br>
All is in the contract that you expect from #new:<br>
You are free to change the semantics of #new: but what makes such a<br>
major change really necessary?<br>
false polymorphism, really?<br></blockquote><div><br></div><div>As I understand, polymorphism has two goals:</div><div>1) To be able to replace the receiver without altering the result of the execution </div><div>2) To simplify vocabulary, to use the same message name for different implementations that have the same semantics. </div><div>The first goal relates to the object, first set, the second to the message names, second set, that is why it is a two-set relationship.</div><div><br></div><div>If you cannot replace an object with another one without altering the execution, then those objects are not polymorphic. </div><div>If the name of the message is the same but its semantics is not, then you can have trouble changing one object for another, therefore they are not polymorphic.</div><div>Having the same message name with different semantics generates confusion, so it is better to avoid it if possible.</div><div>I've seen many smalltalkers send the message #new: to an OrderedCollection assuming that will do the same as with Array, it is a very common mistake.</div><div><br></div><div>But anyway, that is the definition I use and it is the best one I found after many years of research and teaching, but I'm open to new ideas and definitions. </div><div><br></div><div>Cheers!</div><div>Hernan.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Nicolas<br>
<br>
Le mar. 6 févr. 2024 à 20:54, Hernán Wilkinson via Cuis-dev<br>
<<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> a écrit :<br>
><br>
> The definition of polymorphism, sadly, is not clear... Each language/book/culture defines it differently and uses that word differently and sometimes in contradictory ways.<br>
> The definition I like to use after many years of teaching the subject is: "Objects of a set are polymorphic among themselves with respect to a set of messages, if the objects of the first set respond semantically the same to the messages of the second".<br>
> "Semantically the same" means "they do the same thing", no matter how they do it (it implies that parameters must be polymorphic and that the results are polymorphic)<br>
><br>
> If #new: n sent to Array creates a collection of n elements but sent to OrderedCollection does not, then Array and OrderedCollection are not polymorphic with respect to #new:, and therefore you cannot replace one receiver with another.<br>
><br>
> A clear example of Array and OrderedCollection not being polymorphic regarding #new: is:<br>
> (Array new: 10) at: 5 --> returns nil.<br>
> (OrderedCollection new: 10) at: 5 --> gives error<br>
><br>
> This behavior does not follow the "minimum attonishment" principle and therefore it is good to avoid it.<br>
><br>
> It is true that it generates compatibility issues, but I also think that sometimes we should break that compatibility if we believe that what we are doing is better, I do not want Smalltalk neither Cuis to be what Alan Kay said a long time ago: "Once it got into production, it stops evolving due to the compatibility issues" (or something like that).<br>
> It is also true that breaking compatibility should be done with care, and that is why this has been done on the rolling version (6.3), not the stable one (6.2). If we do not want compatibility issues we should work on the stable release and migrate to a different stable version if we want it/need it.<br>
><br>
> When Juan told me about this problem the first thing we talked about was about the compatibility problems it could generate, but the idea of doing something better won over the compatibility idea... We are working on the rolling release and if the change generates more problems than solutions, we can go back to how it was.<br>
><br>
> Let's give it a try and see what happens!<br>
><br>
> Cheers!<br>
> Hernan.<br>
><br>
> On Tue, Feb 6, 2024 at 4:00 PM Luciano Notarfrancesco via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br>
>><br>
>> I would say not the class but the receiver is the only one with the full context, as illustrated by Text>>grownTo: (and other examples in my code)<br>
>><br>
>> On Wed, Feb 7, 2024 at 01:57 Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br>
>>><br>
>>> Be careful with that "false polymorphism" argument. Going down that<br>
>>> route means you can ignore the receiver's class when you see a selector<br>
>>> because a selector can only have one meaning. In a sense, it promotes<br>
>>> selectors to operators.<br>
>>><br>
>>> It should be pretty clear that collections like Array and Set should<br>
>>> behave differently. Why is that being ignored?<br>
>>><br>
>>> Consider this alternate interpretation. The root cause of this problem<br>
>>> seems to be that some code has the expectation that<br>
>>><br>
>>> species new: n<br>
>>><br>
>>> can have exactly one meaning. The sender is ignoring the receiver<br>
>>> class. Only the receiver class has that context. So the receiver class<br>
>>> should be given the task of creating the new instance instead --- this<br>
>>> is why arithmetic has double dispatching, for example.<br>
>>><br>
>>> Andres.<br>
>>><br>
>>> On 2/6/24 8:21 AM, Juan Vuletich via Cuis-dev wrote:<br>
>>> > Let me also elaborate a bit on the rationale.<br>
>>> ><br>
>>> > In Smalltalk-80 (and every other Smalltalk system since then), the docs<br>
>>> > will say that #new: will answer a collection of the requested size. But<br>
>>> > it is not like that for Set, Dictionary, OrderedCollection and a few<br>
>>> > others, that give a completely different semantics to this message. It<br>
>>> > is no _that_ bad when the message is sent to an explicit class, although<br>
>>> > you need to be aware of this.<br>
>>> ><br>
>>> > The real problem is when someone does `someCollection species new:<br>
>>> > aNumber`. It gets really tricky to find out what is going to happen.<br>
>>> ><br>
>>> > This is a prime example of what I call "False Polymorphism". It looks<br>
>>> > like a polymorphic message, but it is not. It is (at least) two sets of<br>
>>> > senders/implementors, completely separated. This means obscure,<br>
>>> > misleading code. It makes me sick. I fix every instance of this I see.<br>
>>> > It rarely happens in the base Smalltalk-80 classes, but it is still wrong.<br>
>>> ><br>
>>> > Thanks,<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>
>><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>
><br>
><br>
><br>
> --<br>
> Hernán Wilkinson<br>
> Agile Software Development, Teaching & Coaching<br>
> Phone: +54-011-4893-2057<br>
> Twitter: @HernanWilkinson<br>
> site: <a href="http://www.10Pines.com" rel="noreferrer" target="_blank">http://www.10Pines.com</a><br>
> Address: Alem 896, Floor 6, Buenos Aires, Argentina<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>
-- <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><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:small"><div dir="ltr"><div dir="ltr"><div style="font-size:12.8px"><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal"><span style="font-weight:bold">Hernán Wilkinson</span><br>Agile Software Development, Teaching & Coaching</span></font></span></span></strong></span></div><div style="font-size:12.8px"><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">Phone: +54-011</span></font></span></span></strong></span><font face="tahoma, sans-serif" size="2">-4893-2057</font></div><div style="font-size:12.8px"><strong style="font-family:tahoma,sans-serif;font-size:xx-small"><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">Twitter: @HernanWilkinson</span></font></span></span></strong></div><div style="font-size:12.8px"><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">site: <a href="http://www.10pines.com/" style="color:rgb(17,65,112)" target="_blank">http://www.10Pines.com</a></span></font></span></span></strong></span></div><div style="font-size:12.8px"><font face="tahoma, sans-serif"><span style="border-collapse:collapse">Address: Alem 896</span></font>, Floor 6, Buenos Aires, Argentina</div></div></div></div></div></div></div></div></div>