True, but I think a name like ‘run super initialization’ would be too namely.
INITIALIZE SUPER ? Better yet, let it take a method (name) as input, with an arrowhead menu option of INITIALIZATION. (Btw, I think this is the only use of “super” for what’s elsewhere called “parent.”)
It adds new functionality, like the IN and IS PROTOTYPE OF block.
Ah. Maybe what I need is a form of documentation for the entire package separate from helpscreens, explaining all the different available object systems (including the primitive ones: dictionaries, sprites, and closures) and laying out all the vocabulary in one place. Libraries should have Notes areas! (@team…)
Magic method definition is ‘magic’ behaviour. It is a reporter to prevent name clashes. Setting the magic parent of an object doesnt just change a slot, it literally changes what the OOP engine looks at.
I mean not my post, your post in this topic about your class/instance OOP (because since it’s a different project, it has it’s own thread here Classes by normal-student-7th).
I think that @onu032001 was trying to get you to look at their project, so posted about it here. They were saying that to get your attention otherwise they would need to @mention you.
@onu032001, @redgeographysnap’s confusion was caused by two things. Mainly, “keep you wake up” is awkward English phrasing. Additionally, by “wake up” I think you meant “attention,” but this was not at all clear. I recognize that English is not your first language, but that is why @redgeographysnap was confused.
How do you handle the ambiguity about inheriting from multiple parents? That is, if the first parent’s parent has a method for some messsage, and the second parent has its own method for the same message, who wins? There are good arguments for both answers, which is why a lot of languages, such as this one, throw up their hands and only have single inheritance paths.
I think you misunderstood what my question is. Of course the first parent wins over the second parent. The question is whether the first grandparent wins over the second parent. If you just send the message to the first parent and accept any method it sends you, then you won’t know that that method comes from a grandparent, so it’ll win. But arguably the second parent’s method is closer to the needs of the child than the first grandparent’s method. The grandparent may have been written without any thought going into how the method will work for grandchildren. As I said, many languages including Snap! avoid the problem by not allowing multiple parents. (I’m not saying that’s what you should do, just that if you do allow multiple inheritance, you should give thought to what you think is the best answer.)
P.S. To accent why the problem is a problem, suppose that classes B and C both inherit from parent class A, which has a FOO method. Class C overrides its parent’s FOO method with one of its own. Now we make class D, which has parents B and C in that order. If the rule is that the first grandparent wins, then you are entirely ignoring the fact that class C thinks it has a better (for its own needs) method for message FOO.
P.P.S. This question is analogous to breadth-first vs. depth-first traversal of a tree, and I’m sure you know that both of those are useful in different contexts.
First it’s this object, second it’s the parents, third it’s each parent of the parents from left to right, …etc.
So the second parent would take priority.
