www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why is this legal?

reply abad <abad.flt gmail.com> writes:
This works:

class Foo {
     protected void bar() {
         writeln("hello from foo");
     }
}

void main() {
     auto foo = new Foo;
     foo.bar();
}

Is this on purpose and what's the rationale?
Mar 29
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 29/03/2017 10:50 AM, abad wrote:
 This works:

 class Foo {
     protected void bar() {
         writeln("hello from foo");
     }
 }

 void main() {
     auto foo = new Foo;
     foo.bar();
 }

 Is this on purpose and what's the rationale?
http://dlang.org/spec/attribute.html#visibility_attributes "protected only applies inside classes (and templates as they can be mixed in) and means that a symbol can only be seen by members of the same module, or by a derived class. If accessing a protected instance member through a derived class member function, that member can only be accessed for the object instance which can be implicitly cast to the same type as ‘this’. protected module members are illegal."
Mar 29
parent Jonathan M Davis via Digitalmars-d-learn writes:
On Wednesday, March 29, 2017 10:56:34 rikki cattermole via Digitalmars-d-
learn wrote:
 On 29/03/2017 10:50 AM, abad wrote:
 This works:

 class Foo {

     protected void bar() {

         writeln("hello from foo");

     }

 }

 void main() {

     auto foo = new Foo;
     foo.bar();

 }

 Is this on purpose and what's the rationale?
http://dlang.org/spec/attribute.html#visibility_attributes "protected only applies inside classes (and templates as they can be mixed in) and means that a symbol can only be seen by members of the same module, or by a derived class. If accessing a protected instance member through a derived class member function, that member can only be accessed for the object instance which can be implicitly cast to the same type as ‘this’. protected module members are illegal."
Yeah, everything in a module can see everything else in a module. It avoids needing to add the complication of friend function and classes like in C++. Basically, it's like everything within a module were declared as friends. If you want something to not have access to something else, then it's going to need to be put in a separate module. - Jonathan M Davis
Mar 29
prev sibling next sibling parent abad <abad.flt gmail.com> writes:
Never mind, it's working OK if the class is defined in another 
module.
Mar 29
prev sibling next sibling parent reply abad <abad.flt gmail.com> writes:
Related question, it seems that final methods are allowed in 
interfaces. Obviously you can't implement them anywhere, so is 
this also on purpose and on what rationale? :)
Mar 29
next sibling parent reply abad <abad.flt gmail.com> writes:
On Wednesday, 29 March 2017 at 10:08:02 UTC, abad wrote:
 Related question, it seems that final methods are allowed in 
 interfaces. Obviously you can't implement them anywhere, so is 
 this also on purpose and on what rationale? :)
So actually it's just a question of not catching this mistake early, because obviously compilation will fail when any class tries to implement the interface so the end result is ok. Maybe it _could_ just disallow final methods altogether to catch the errors earlier. But very minor detail overall.
Mar 29
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Wednesday, 29 March 2017 at 10:12:08 UTC, abad wrote:
 On Wednesday, 29 March 2017 at 10:08:02 UTC, abad wrote:
 Related question, it seems that final methods are allowed in 
 interfaces. Obviously you can't implement them anywhere, so is 
 this also on purpose and on what rationale? :)
So actually it's just a question of not catching this mistake early, because obviously compilation will fail when any class tries to implement the interface so the end result is ok. Maybe it _could_ just disallow final methods altogether to catch the errors earlier. But very minor detail overall.
The idea between `final` functions in interfaces is to provide a default non-overridable implementation. For example: interface Lockable { void lock(); void unlock(); alias Action = void delegate(); final void performLocked(Action action) { lock(); // Ensures that the lock will be released after `action` // is called, even if throws an exception. scope(exit) unlock(); action(); } } class Mutex : Lockable { void lock() { /* ... */ } void unlock() { /* ... */ } // Can't override `performLocked` differently } A common example is frameworks which provide customization points for applications through non-final interface functions, but overall take-over the application control flow: interface App { /// Main application loop final bool run() { init(); while(handleInput()) { update(); auto frame = render(); // implement somewhere else as a free function present(frame); } return true; } /// Initializes the application's resources on startup. void init(); /// Handles the input. /// Returns: /// false - if the app should be closed and true - otherwise. bool handleInput(); /// Updates the application state after handling input. void update(); /// Renders and the next frame into a buffer and /// returns a reference to it. Framerender(); } Other times, it's just for convenience in generic code: interface SceneDscNode { final T get(T)() const { static if (isBoolean!T) return getBool(); else static if (isIntegral!T) return getInt.to!T(); else static if (isFloatingPoint!T) return getFloat.to!T(); else static if (isSomeString!T) return getString.to!T(); else static assert(0, "Type not supported: " ~ T.stringof); } string getName() const; SceneDscNode getChild(string propertyName) const; SceneDscNode[] getChildren() const; protected: bool getBool() const; long getInt() const; double getFloat() const; string getString() const; } class JsonValueWrapper : SceneDscNode { string getName() const { /* ... */ } SceneDscNode getChild(string propertyName) const { /* ... */ } SceneDscNode[] getChildren() const { /* ... */ } protected { bool getBool() const { /* ... */ } long getInt() const { /* ... */ } double getFloat() const { /* ... */ } string getString() const { /* ... */ } } private JSONValue json; } class SdlValueWrapper : SceneDscNode { string getName() const { /* ... */ } SceneDscNode getChild(string propertyName) const { /* ... */ } SceneDscNode[] getChildren() const { /* ... */ } protected { bool getBool() const { /* ... */ } long getInt() const { /* ... */ } double getFloat() const { /* ... */ } string getString() const { /* ... */ } } private const SDLTag sdl; }
Mar 29
parent reply abad <abad.flt gmail.com> writes:
On Wednesday, 29 March 2017 at 11:06:55 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Wednesday, 29 March 2017 at 10:12:08 UTC, abad wrote:
 On Wednesday, 29 March 2017 at 10:08:02 UTC, abad wrote:
 Related question, it seems that final methods are allowed in 
 interfaces. Obviously you can't implement them anywhere, so 
 is this also on purpose and on what rationale? :)
So actually it's just a question of not catching this mistake early, because obviously compilation will fail when any class tries to implement the interface so the end result is ok. Maybe it _could_ just disallow final methods altogether to catch the errors earlier. But very minor detail overall.
The idea between `final` functions in interfaces is to provide a default non-overridable implementation. For example:
Yes, does make sense. I was looking this from Java 7 perspective where interfaces can't implement any methods.
Mar 29
parent Mike Parker <aldacron gmail.com> writes:
On Wednesday, 29 March 2017 at 11:17:48 UTC, abad wrote:

 Yes, does make sense. I was looking this from Java 7 
 perspective where interfaces can't implement any methods.
D did not support them either for much of its history. IIRC, we got them at some point after Java did.
Mar 29
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Wednesday, March 29, 2017 10:08:02 abad via Digitalmars-d-learn wrote:
 Related question, it seems that final methods are allowed in
 interfaces. Obviously you can't implement them anywhere, so is
 this also on purpose and on what rationale? :)
If the function is final, it can have an implementation. interface I { final bool foo() { return true; } } class C : I { } void main() { } - Jonathan M Davis
Mar 29
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Wednesday, March 29, 2017 10:08:02 abad via Digitalmars-d-learn wrote:
 Related question, it seems that final methods are allowed in
 interfaces. Obviously you can't implement them anywhere, so is
 this also on purpose and on what rationale? :)
If the function is final, it can have an implementation. interface I { final bool foo() { return true; } } class C : I { } void main() { } - Jonathan M Davis
Mar 29
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Wed, Mar 29, 2017 at 11:24:04AM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
 On Wednesday, March 29, 2017 10:08:02 abad via Digitalmars-d-learn wrote:
 Related question, it seems that final methods are allowed in
 interfaces. Obviously you can't implement them anywhere, so is
 this also on purpose and on what rationale? :)
If the function is final, it can have an implementation.
[...] If a function is final, it *must* have an implementation, since there can be no further overrides that would provide one in a derived type. The rationale for allowing final methods in an interface is to provide users of the interface with nice syntactic sugar, e.g., a set of methods that are commonly used together abstracted into a single final method, while requiring subclasses to only implement a smaller number of orthogonal methods that can be used to implement that method. T -- When solving a problem, take care that you do not become part of the problem.
Mar 29
prev sibling parent bauss <jj_1337 live.dk> writes:
On Wednesday, 29 March 2017 at 10:08:02 UTC, abad wrote:
 Related question, it seems that final methods are allowed in 
 interfaces. Obviously you can't implement them anywhere, so is 
 this also on purpose and on what rationale? :)
That is not necessarily true. Final doesn't imply it can't be implemented. It implies that it cannot be override.
Mar 30
prev sibling parent XavierAP <n3minis-git yahoo.es> writes:
On Wednesday, 29 March 2017 at 09:50:10 UTC, abad wrote:
 
 Is this on purpose and what's the rationale?
In Andrei's book, chapter 6.9.1 "the non virtual interface (NVI) idiom" answers your question. It cites this article by Herb Sutter as the originator of the idea: http://www.gotw.ca/publications/mill18.htm
Mar 29