.. (לתיקייה המכילה) | ||
Can we assume that you won't try to create an instance of MyObject? | |
Yes. We won't create an instance of MyObject, and MyObject will not appear as one of the multiple parents in the new model. |
In the examples, why does function foo3 defined in class C cause an error? | |
Note that in this case an instance of C is the sender and an instance of F is the receiver. foo is protected in F, and C doesn't inherit from F so according to the rules of the assignment C can't call foo in F. |
What should "SomeClass multInheritsFrom: Object" and "SomeClass multInheritsFrom: MyObject" return? | |
These won't be tested. |
Clearing up some questions about ambiguity in the method classifyInheritedMethod: | |
According to the assignment, the method returns 'ambiguity' in the following two cases: 1. The method is defined for the first time in at least two different parent classes (for the first time means that this isn't a case of overriding) 2. The method is defined for the first time in a single class, but there are at least two different paths from the current class to the defining class. Two different paths means two distinctly different paths – if all of the paths are subsets of one of the paths then they are not considered distinctly different. This means that the if B inherits from A and A sees function foo as 'ambiguity', then B also sees foo as 'ambiguity'. This is true EVEN IF A defines foo as well. Note that this is NOT what happens in C++. C++ supports what is called a "unique file overrider". We will learn about this in the tutorial on multiple inheritance. |
In the methods in part 3, what should we do in the case of overriding where there is no ambiguity? | |
If there is no ambiguity, the methods in part 3 look at the most-overriding version of a method (that is in an ancestor of the current class), as would be expected |