On 18.05.2013 21:51, Walter Bright wrote:
On 5/18/2013 12:28 PM, Andrej Mitrovic wrote:
On 5/18/13, Walter Bright <[email protected]> wrote:
I don't agree. A base class's scope must override the top level module
scope.
Also, a base class can always override what a derived class does.
This is
not hijacking.
Don't you see that this change in behavior is going to surprise a lot
of people? It's intuitive to me that this is going to cause trouble
down the road. A base class could be in another file, in another
library, and if the library writer decides to introduce a scoped
import, suddenly the user's code might end up calling the wrong
function (if the type signatures are the same the user will have *no
idea* what happened). This is the definition of function hijacking.
If it is a feature, it is not properly documented, and I can't tell
which pull request changed the behavior so I don't know whether to put
it in the changelog or not.
Kenji, maybe you know?
I agree that it is changing behavior, and should be properly documented.
However, I also believe it is correct behavior and fixed a bug.
It's *always* true that when you change a base class, you affect the
derived classes.
I think the new behaviour is consistent with symbol lookup rules, but
I'm not so sure about import rules. The actual case that triggered the
issue was with the base class in a different file. Usually non-public
imports in a module don't have an effect on another module that imports
the module. In this case it has.
Actually, I can live with it, but I cannot see a reasonable use case for
the new behaviour. My rule of thumb would be to not use local import in
classes. Otherwise all imported symbols are treated as static members
with respect to lookup, hiding global functions or variables in derived
classes.
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
