.. (לתיקייה המכילה) | ||
I don't understand where, in the inheritance chain, to put 'MyObject'. | |
'MyObject' is simulating 'Object' and should inherit from 'Object'. It is considered as "The root of inheritance" in this assignment (as we do not want to alter 'Object'). All relevant classes, that are to be affected due to this assignment (e.g. affected by compile:where:, isKindOf:, etc...) should inherit (directly or indirectly) from 'MyObject'. |
In part 2, method (2), the backwards compatible subclass:..., what should we do it there happen to be that a class 'wants' to derive from an interface? e.g. IA subclass #A ... | |
You should throw exception 2.3 like in method (1). |
It is written in the assignment that methods for an interface will not be compiled with constraint. Does it mean the the param for `where:` will be an empty collection? or compile:where: will not be called at all? | |
The message 'compile:where:' will not be sent to an interface. Let IA be an interface; this means, that IA compile: 'foo:x where: {nil}' is ILLEGAL and won't be checked. You can assume, that the only way to add methods to IA is via `compile:` |
A method with an empty line, comment as second line- what to do with it? | |
Such methods (obviously) have more than 1 line, so, by definition, they are considered as *non*-empty. But, such bizarre cases won't be tested (maybe in intro to CS) Another bizarre cases that won't be tested: A comment in the first line somewhere among the selector, 2 lines of local variable definitions, etc... |
Is is written that an interface should not have state. Does it includes classVariableNames as well? | |
No. 'classVariableNames' do not describe the *instance* state. |
I find hard to understand the requirements of ambiguous. What methods are considered as ambiguous? | |
A method is considered ambiguous (amb.) FOR THE RECEIVER if it should be implemented in more that one interface that the receiver behaves like. You can look that when an interface behaves like another interface, it 'takes' all his methods. Examples: 1. I1 and I2 define foo, and A behaves like I1 and I2 --> foo is amb. when A is the receiver 2. I1 defines foo, I2 behaves like I1, and A behaves like I2 --> foo is amb. when A is the receiver AND when I2 is the receiver; since I1 defined foo and I2 "has" foo as well. 3. IA defines foo, I1 and I2 behaves like IA, and A behaves like IA --> foo is amb. only when I1 or I2 are the receivers; if A where behaving (in addition or not) like I1 or I2 (or both) then foo is amb. for A. |
An empty method in a class which is not an interface - is it legal, etc? | |
The definition of empty methods holds only for the sake of interfaces. An empty method is OK when it is compiled in a class and is considered as a 'regular' method. |