Re: Why is this legal?
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.
Re: Why is this legal?
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
Re: Why is this legal?
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.
Re: Why is this legal?
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
Re: Why is this legal?
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.
Re: Why is this legal?
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.
Re: Why is this legal?
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;
}
Re: Why is this legal?
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
Re: Why is this legal?
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.
Re: Why is this legal?
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? :)
Re: Why is this legal?
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
Re: Why is this legal?
Never mind, it's working OK if the class is defined in another module.
Re: Why is this legal?
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."
Why is this legal?
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?
