A feature that I find missing in D is the ability to write functions in interfaces that can call other functions of the interface. Given an interface ISomeInteface the only way we can write a general purpose function to operate on all objects which implement that interface is through the following style of declaration :

    FuBar(ISomeInterface i) { ... };

Which when invoked requires the following syntax :

    FuBar(i);

What would be more keeping with the spirit of object oriented syntax would be to be able to define interface functions which allow the more straightforward object-like syntax of :

    i.FuBar();

For lack of a better term I refer to these kinds of functions as interface extensions, in order to distinguish them from interface contract (the set of functions to be implemented, by an implementor of the interface). One possible approach for adding this feature is to prefix extension functions with a keyword modifier, such as in the following notation :

    SomeInterface {
        extension FuBar() { ... }
    }

Another possibility, and my preferred option, is to divide the interface into two sections :

    SomeInterface {
        contract
            ...
        extension
            FuBar();
    }

For those interested there is a draft of a paper on this feature as it is proposed in Heron at http://www.heron-language.com/extensions.html . I would like to know what others think of this proposal. Thanks in advance for your feedback.

-- 
Christopher Diggins
yet another language designer
http://www.heron-language.com

In article <bvreas$23u9$1@digitaldaemon.com>, christopher diggins says...
>
>A feature that I find missing in D is the ability to write functions in interfaces that can call other functions of the interface. Given an interface ISomeInteface the only way we can write a general purpose function to operate on all objects which implement that interface is

..

The following page has an interesting discussion about the issue:

http://www.heron-language.com/extensions.html

"
Interfaces with extensions and a mechanism for delegating
implementation to member fields can replace entirely class
inheritance as a means for providing polymorphic objects.
Such a system would have advantages in that it supports yet
clearly distinguishes between inheritance of a role (interface)
and inheritance of implementation.
"

While this does sound, er, unbelievable, to me, if there's half a truth in this, then this could mean that the major part of OO code existing today could be rewritten.

(This does not necessarily bear a precedent, but this reminds me of C++ and multiple inheritance.) MI was one of the most ferrociously advocated features in C++ in the late '80s. Only afterwards it became clear that there was actually (almost) no use for the feature. Multiple paths from the same ancestor class screwed up the issue. (Not to mention it was one hell for bigW and others who actually had to conjure up the stuff!)

Until someone (sorry, I forget who) demostrated that all you have to do is to have the interface multiply inherited, then you don't have to MI any implementation -- as a matter of fact, you really _shouldn't_.

If the interface definition would allow us to have functions call
each other, then it would be easy to convey in the ID that you
may have only a very few functions that actually do any manipulation
of the attributes. This could lead to code that is less dependent
on details, and code that is easier to maintain. If the internal
definitions of attributes change, then this way only the _very_
few functions that actually manipulate the attributes would have
to change. The other interface functions (could be considered
clients of these, and therefore) would not need any modifications.

While I wouldn't even dream of skipping D for Heron, I have to admit that there are quite some things Heron seems to do right!

Separate operators for value and reference assignment is the absolutely most brilliant idea I have ever seen in a language. And there are others.

Interesting proposal - allow multiple inheritance of classes without fields. If the implementations of any inherited method are all the same then it would be ok, I suppose. This is unlike inheriting multiple copies of a field since the name becomes ambiguous. I've grown used to the mantra "classes have code/data and interfaces don't" so the lack of this feature in D doesn't bother me.

On a side note, I read in the D doc that it is illegal to inherit duplicate interfaces:

interface D
	{
	    void foo();
	}
	class A : D, D	// error, duplicate interface
	{
	}

But is this legal:

interface D
{
    void foo();
}
interface D2 : D
{
}
class A : D, D2
{
}

Why rule out duplicate interfaces when you can just create an empty sub-interface? If the first breaks some compiler logic one would think the second one would, too.

-Ben

"christopher diggins" <cdiggins@users.sourceforge.net> wrote in message
news:bvreas$23u9$1@digitaldaemon.com...
| A feature that I find missing in D is the ability to write functions in
| interfaces that can call other functions of the interface. Given an
| interface ISomeInteface the only way we can write a general purpose
function
| to operate on all objects which implement that interface is through the
| following style of declaration :
|
|     FuBar(ISomeInterface i) { ... };
|
| Which when invoked requires the following syntax :
|
|     FuBar(i);
|
| What would be more keeping with the spirit of object oriented syntax would
| be to be able to define interface functions which allow the more
| straightforward object-like syntax of :
|
|     i.FuBar();
|
| For lack of a better term I refer to these kinds of functions as interface
| extensions, in order to distinguish them from interface contract (the set
of
| functions to be implemented, by an implementor of the interface). One
| possible approach for adding this feature is to prefix extension functions
| with a keyword modifier, such as in the following notation :
|
|     SomeInterface {
|         extension FuBar() { ... }
|     }
|
| Another possibility, and my preferred option, is to divide the interface
| into two sections :
|
|     SomeInterface {
|         contract
|             ...
|         extension
|             FuBar();
|     }
|
| For those interested there is a draft of a paper on this feature as it is
| proposed in Heron at http://www.heron-language.com/extensions.html . I
would
| like to know what others think of this proposal. Thanks in advance for
your
| feedback.
|
| --
| Christopher Diggins
| yet another language designer
| http://www.heron-language.com
|
|

"Georg Wrede" <Georg_member@pathlink.com> wrote in message news:bvrvdm$30or$1@digitaldaemon.com...
> In article <bvreas$23u9$1@digitaldaemon.com>, christopher diggins says...
> >
> >A feature that I find missing in D is the ability to write functions in interfaces that can call other functions of the interface. Given an interface ISomeInteface the only way we can write a general purpose function to operate on all objects which implement that interface is
>
> ..
>
> The following page has an interesting discussion about the issue:
>
> http://www.heron-language.com/extensions.html
>
> "
> Interfaces with extensions and a mechanism for delegating
> implementation to member fields can replace entirely class
> inheritance as a means for providing polymorphic objects.
> Such a system would have advantages in that it supports yet
> clearly distinguishes between inheritance of a role (interface)
> and inheritance of implementation.
> "
>
> While this does sound, er, unbelievable, to me, if there's half a truth in this, then this could mean that the major part of OO code existing today could be rewritten.

Well I am reasonably confident that what I propose is wholly true, I don't see rewriting existing OO code as a goal. Just perhaps that people would abandon the misuse of virtual functions.

> (This does not necessarily bear a precedent, but this reminds me of C++ and multiple inheritance.) MI was one of the most ferrociously advocated features in C++ in the late '80s. Only afterwards it became clear that there was actually (almost) no use for the feature. Multiple paths from the same ancestor class screwed up the issue. (Not to mention it was one hell for bigW and others who actually had to conjure up the stuff!)
>
> Until someone (sorry, I forget who) demostrated that all you have to do is to have the interface multiply inherited, then you don't have to MI any implementation -- as a matter of fact, you really _shouldn't_.
>
> If the interface definition would allow us to have functions call
> each other, then it would be easy to convey in the ID that you
> may have only a very few functions that actually do any manipulation
> of the attributes. This could lead to code that is less dependent
> on details, and code that is easier to maintain. If the internal
> definitions of attributes change, then this way only the _very_
> few functions that actually manipulate the attributes would have
> to change. The other interface functions (could be considered
> clients of these, and therefore) would not need any modifications.

I am glad you see this the same way that I do. This was exactly the design intention when I introduced it into Heron. So perhaps we should petition Walter together to consider including it in D?

> While I wouldn't even dream of skipping D for Heron, I have to admit that there are quite some things Heron seems to do right!
>
> Separate operators for value and reference assignment is the absolutely most brilliant idea I have ever seen in a language. And there are others.

Very kind words, Georg, thank you.

-- 
Christopher Diggins
yet another language designer
http://www.heron-language.com

Hi Christopher.

I read the paper, and this post, carefully, but I'm let down my a kinetic mind. I need to see real examples, otherwise it's all just fuzz to me.

If you have the time, I'd very much appreciate your providing a fleshed out example to demonstrate what you mean, and from which I can make a reasoned assessment of your idea.

Cheers

Matthew


"christopher diggins" <cdiggins@users.sourceforge.net> wrote in message news:bvreas$23u9$1@digitaldaemon.com...
> A feature that I find missing in D is the ability to write functions in interfaces that can call other functions of the interface. Given an interface ISomeInteface the only way we can write a general purpose
function
> to operate on all objects which implement that interface is through the following style of declaration :
>
>     FuBar(ISomeInterface i) { ... };
>
> Which when invoked requires the following syntax :
>
>     FuBar(i);
>
> What would be more keeping with the spirit of object oriented syntax would be to be able to define interface functions which allow the more straightforward object-like syntax of :
>
>     i.FuBar();
>
> For lack of a better term I refer to these kinds of functions as interface extensions, in order to distinguish them from interface contract (the set
of
> functions to be implemented, by an implementor of the interface). One possible approach for adding this feature is to prefix extension functions with a keyword modifier, such as in the following notation :
>
>     SomeInterface {
>         extension FuBar() { ... }
>     }
>
> Another possibility, and my preferred option, is to divide the interface into two sections :
>
>     SomeInterface {
>         contract
>             ...
>         extension
>             FuBar();
>     }
>
> For those interested there is a draft of a paper on this feature as it is proposed in Heron at http://www.heron-language.com/extensions.html . I
would
> like to know what others think of this proposal. Thanks in advance for
your
> feedback.
>
> -- 
> Christopher Diggins
> yet another language designer
> http://www.heron-language.com
>
>

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:bvrvvn$31iu$1@digitaldaemon.com...
> Interesting proposal - allow multiple inheritance of classes without
fields.
> If the implementations of any inherited method are all the same then it would be ok, I suppose. This is unlike inheriting multiple copies of a
field
> since the name becomes ambiguous. I've grown used to the mantra "classes have code/data and interfaces don't" so the lack of this feature in D doesn't bother me.
>
> On a side note, I read in the D doc that it is illegal to inherit
duplicate
> interfaces:
>
> interface D
> {
>     void foo();
> }
> class A : D, D // error, duplicate interface
> {
> }

This is entirely meaningless. There's no difference between class A : D {} and class A : D, D, D, D, D, D, ... , D {}, because all you can do with A is deduce that it is of type A or of type D.

> But is this legal:
>
> interface D
> {
>     void foo();
> }
> interface D2 : D
> {
> }
> class A : D, D2
> {
> }

I didn't know D allowed this. If it does, I think it shouldn't. C++ does not.

Something like the following is legal

interface D{};
interface D1 : D {};
interface D2 : D {};
class A : D1, D2 {};

This is useful. If D1 and/or D2 provide additional functionality, then the benefit is obvious. However, even if they provide no additional functionality it can still be useful, in the same way that COM uses empty "tag" interfaces. Of course, I hate RTTI with a grand passion, so I'm being somewhat hypocritical here, but you can see that there is technical merit in the ability to deduce whether A is of type D1 and/or D2.

>
> Why rule out duplicate interfaces when you can just create an empty sub-interface? If the first breaks some compiler logic one would think the second one would, too.
>
> -Ben
>
> "christopher diggins" <cdiggins@users.sourceforge.net> wrote in message
> news:bvreas$23u9$1@digitaldaemon.com...
> | A feature that I find missing in D is the ability to write functions in
> | interfaces that can call other functions of the interface. Given an
> | interface ISomeInteface the only way we can write a general purpose
> function
> | to operate on all objects which implement that interface is through the
> | following style of declaration :
> |
> |     FuBar(ISomeInterface i) { ... };
> |
> | Which when invoked requires the following syntax :
> |
> |     FuBar(i);
> |
> | What would be more keeping with the spirit of object oriented syntax
would
> | be to be able to define interface functions which allow the more
> | straightforward object-like syntax of :
> |
> |     i.FuBar();
> |
> | For lack of a better term I refer to these kinds of functions as
interface
> | extensions, in order to distinguish them from interface contract (the
set
> of
> | functions to be implemented, by an implementor of the interface). One
> | possible approach for adding this feature is to prefix extension
functions
> | with a keyword modifier, such as in the following notation :
> |
> |     SomeInterface {
> |         extension FuBar() { ... }
> |     }
> |
> | Another possibility, and my preferred option, is to divide the interface
> | into two sections :
> |
> |     SomeInterface {
> |         contract
> |             ...
> |         extension
> |             FuBar();
> |     }
> |
> | For those interested there is a draft of a paper on this feature as it
is
> | proposed in Heron at http://www.heron-language.com/extensions.html . I
> would
> | like to know what others think of this proposal. Thanks in advance for
> your
> | feedback.
> |
> | --
> | Christopher Diggins
> | yet another language designer
> | http://www.heron-language.com
> |
> |
>
>

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bvs44p$6da$1@digitaldaemon.com...
> Hi Christopher.
>
> I read the paper, and this post, carefully, but I'm let down my a kinetic mind. I need to see real examples, otherwise it's all just fuzz to me.
>
> If you have the time, I'd very much appreciate your providing a fleshed
out
> example to demonstrate what you mean, and from which I can make a reasoned assessment of your idea.
>
> Cheers
>
> Matthew


Hi Matthew,

There is an example in the paper involving Binary Search Trees. The first part of the example is an interface for an ITreeNode which demonstrates how four functions make up the contract : GetValue, GetLeftChild, GetRightChild, GetParent. We then can deduce four functions :GetMinimum, GetMaximum, GetSuccessor, GetPredecessor; as an extension. Those are functions that essentially come for free for any class that implements the contracts of the extension. What is troublesome for you with this example?

If I may try to simplify it, the concept is that for certain interfaces there are many functions which can be defined in terms of other functions of that particular interface. This is an extension.

To bring in a perhaps less abstract example :

interface IString {
  contract
    GetNumChars() : int;
    GetChar(int i) : char;
    SetNumChars(int n);
    SetChar(int i, char c);
  extension
    Append(IString& s);
    ConvertToUppercase();
    ConvertToLowercase();
    ReverseStr();
    SetAllCharsTo(char c);
    Clear();
    ...
}

The extension are all the functions that you can imagine defining from the first part. How am I doing?

-- 
Christopher Diggins
yet another language designer
http://www.heron-language.com

Author: "christopher diggins" <cdiggins@users.sourceforge.net>
> 
> I am glad you see this the same way that I do. This was exactly the design intention when I introduced it into Heron. So perhaps we should petition Walter together to consider including it in D?

D does not separate declaration from definition, so there
might not even be any need for new keywords (such as contract or
extension). Anybody could see right away that some of the
methods have bodies, and since this is an interface, they must
be Extensions.

OTOH, it might be clearer for the reader (and writer himself)
if the words contract and extension were there. (But if you
don't use extensions, then neither word has to be there.)

What do you think is the minimum set of rules the compiler would have to have, if we were to implement extensions?

"Georg Wrede" <Georg_member@pathlink.com> wrote in message news:bvu8lv$nt0$1@digitaldaemon.com...
> Author: "christopher diggins" <cdiggins@users.sourceforge.net>
> >
> > I am glad you see this the same way that I do. This was exactly the design intention when I introduced it into Heron. So perhaps we should petition Walter together to consider including it in D?
>
> D does not separate declaration from definition, so there
> might not even be any need for new keywords (such as contract or
> extension). Anybody could see right away that some of the
> methods have bodies, and since this is an interface, they must
> be Extensions.
>
> OTOH, it might be clearer for the reader (and writer himself)
> if the words contract and extension were there. (But if you
> don't use extensions, then neither word has to be there.)

I do think it would be clearer to at the very minimum identify extension functions, so that users don't think they are supposed to provide an implementation for that function.

> What do you think is the minimum set of rules the compiler would have to have, if we were to implement extensions?

Well to cause the least syntactic disruption, we could introduce it as follows :

interface IFuBar {
    void RegularIntefaceFxn();
    extension void ExtensionFxn() { RegularInterfaceFxn() };
}

The compiler could automatically generate the function for any class implementing IFuBar exactly as it appears. I don't know how naming conflicts are dealt with in the D compiler, but the same solution that is used to resolve naming conflicts between multiple interfaces within a class could likely be used. Am I on the right track?

By the way Georg I tried sending you a private email to participate in
discussions on Heron, but it bounced back. May I write you privately? You
can email me at cdiggins@users.sourceforge.net to give me another address I
can use.
Thanks

-- 
Christopher Diggins
yet another language designer
http://www.heron-language.com

In article <bvu9ql$psb$1@digitaldaemon.com>, christopher diggins says...
>
>> What do you think is the minimum set of rules the compiler would have to have, if we were to implement extensions?
>
>Well to cause the least syntactic disruption, we could introduce it as follows :
>
>interface IFuBar {
>    void RegularIntefaceFxn();
>    extension void ExtensionFxn() { RegularInterfaceFxn() };
>}

This seems quite reasonable.

>The compiler could automatically generate the function for any class implementing IFuBar exactly as it appears.

Yes, this would save typing, and prevent unnecessary bugs in user code. And of course, the child class may freely reimplement any or all of them if need be.

>I don't know how naming conflicts
>are dealt with in the D compiler, but the same solution that is used to
>resolve naming conflicts between multiple interfaces within a class could
>likely be used.

Good point.

>Am I on the right track?

I was thinking more like the dos and don'ts of extensions. Since you've obviously used this tehnique for some time, you may have ideas on what the programmer could be allowed to write in an extension function.

The interface function can't do anything, it's supposed to be totally implemented by the inheriting class. In the same way, the extension function can't assume things about the internals of the inheriting class. And to enforce this, I thought the compiler could error such code. Also, I wouldn't be surprised if it were wise to further limit this code somehow -- but right now this is just a gut feeling.