Unexpected behaviour with "learn" message and inheritance. about citrine HOT 4 CLOSED

Thank you, for reporting this, I am now looking into this.

from citrine.

Just refreshed my memory by looking into the source. The method function is copied to the new object, so it should not call the parent method. The reason for the described behaviour is that both Object and Nil have their own implementation of Nil?. Object always returns False, while Nil always returns True. So this:

Object learn: 'is nil' means: 'Nil?'.
Nil learn: 'is nil' means: 'Nil?'.

✎ write: Nil is nil.
✎ write: Nil Nil?.
✎ write: Object is nil.
✎ write: 5 is nil.
✎ write: 'ABC' is nil.

will give you:

TrueTrueFalseFalseFalse

Does this help / clarify anything?

from citrine.

Thanks for the response, though I'd already noticed that workaround for that simple example. It's just that more generally it feels unnatural to me to define an alias and not have it apply to derived objects too.
Right now, if I define an alias, I have no guarantee that it does the same thing as the original function unless I'm working on the specific object on which I set the alias (and I can be almost certain it doesn't if it's not directly derived from that object).
If I wanted to be reasonably sure an alias and the function it's aliasing do the same thing when sent to an arbitrary object, even if neither my program nor any libraries I use define any new types, I'd have to make 13 different learn calls (on Object, Block, Boolean, Moment, File, Json, List, Map, Nil, Number, ✎, Program and String), depending on the method in question. If someone else might use my code in their own program I have literally no way to make sure my code works as expected if I use aliases, because I can't add aliases on types that I don't even know about.

It sounds like you're saying that's all intentional, though, which would mean I'm just misunderstanding when and how learn is supposed to be used.

from citrine.

You don't have to use learn 13 times, just 2. The procedure works exactly as you expect it does (as far as I understand your expectations). The learned behavior will apply to all derived objects. Unfortunately, for Nil? the exception is that the default behaviour is overridden by Nil. The reasoning behind this is: all objects will claim they are not Nil, except Nil (because Nil overrides that method). I could change how this works, but then every object has to check whether it is Nil for itself upon receiving Nil? which kinds of defeats the purpose of OOP to reduce code and if-conditions. It will also make code slower, because then every object has to perform check while most objects, because they inherit directly from Object and not from Nil already know the answer to Nil? Namely, False.

Learn is meant to finetune the language for readability. If you want to have a localized version of Citrine in a language other than English, simply translate the header files and compile a localized version.

Maybe some sort of object diagram should be added to the documentation?

from citrine.