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?

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."

Never mind, it's working OK if the class is defined in another module.

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

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? :)

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.

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

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;
}

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.

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.