christopher diggins wrote:
> 
> Well to cause the least syntactic disruption, we could introduce it as
> follows :
> 
> interface IFuBar {
>     void RegularIntefaceFxn();
>     extension void ExtensionFxn() { RegularInterfaceFxn() };
> }
> 

Nearly every abstract class I write follows this pattern.  It's a good idiom.  Is the 'extension' keyword really needed?  It's unambigious as far as I can tell: methods that are defined are extensions, methods that are not are part of the contract.

This is kind of interesting in that it nearly unifies classes and interfaces.  The latter is merely forbidden from containing attributes or extending classes.

 -- andy

"Georg Wrede" <Georg_member@pathlink.com> wrote in message news:bvvmcl$c3$1@digitaldaemon.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.

That would lead to a naming conflict, which I suppose we could resolve by having the class itself hide any extension implementation. A problem arises within an extension function A when it calls another extension function B which is reimplemented by the class as function C. Does A call B or C? In Heron I currently specify that A calls B. Perhaps it is more intuitive to most that A calls C.

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

Oh I see, so we need to explicitly say to the compiler what it can see. It can't call any functions except those of the interface (and any sub-interfaces) and it can't access any fields. It can access anything in the

At this point though I think I should stop posting on this topic since no one else, other than Georg, seems to be interested. I made similar feature proposals on the Java and C# newsgroups, and the interest in it was virtually nil. Most of the topics are along the lines of "this is too much like MI therefore it is bad". I guess not many people are able to (or perhaps don't want to?) see the advantage of this feature. Spending further energy working out how to incorporate the feature in D seems pointless if Walter isn't interested.

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

"Andy Friesen" <andy@ikagames.com> wrote in message news:c00glo$1bfc$1@digitaldaemon.com...
> christopher diggins wrote:
> >
> > Well to cause the least syntactic disruption, we could introduce it as follows :
> >
> > interface IFuBar {
> >     void RegularIntefaceFxn();
> >     extension void ExtensionFxn() { RegularInterfaceFxn() };
> > }
> >
>
> Nearly every abstract class I write follows this pattern.  It's a good idiom.  Is the 'extension' keyword really needed?  It's unambigious as far as I can tell: methods that are defined are extensions, methods that are not are part of the contract.

Well it depends on whether we actually allow the extension to be implemented by the class as an override or hidden, or a naming conflict that must be explicitly resolved.

> This is kind of interesting in that it nearly unifies classes and interfaces.  The latter is merely forbidden from containing attributes or extending classes.

This identifies part of the reason for the extension. With one other mechanism (interface implementation delegation to member fields), we could create object oriented designs without class inheritance. Part of my premise is that class inheritance as is commonly implemented, is an inherently flawed mechanism.

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

<snip>

> At this point though I think I should stop posting on this topic since no one else, other than Georg, seems to be interested. I made similar feature proposals on the Java and C# newsgroups, and the interest in it was virtually nil. Most of the topics are along the lines of "this is too much like MI therefore it is bad". I guess not many people are able to (or perhaps don't want to?) see the advantage of this feature.

I want to see the point, but I just don't. I think you need to provide us with a clear and compelling (by which I mean non-trival, "real") example.

I understand the mechanism, and have used the technique here and there in C/COM/C++, but I just don't get the "higher" significance that your propounding. Don't get me wrong: I'm open to the idea that you're onto something significant, and I want to see it. I just don't, yet. Please pursue it.

> Spending further
> energy working out how to incorporate the feature in D seems pointless if
> Walter isn't interested.

This NG doesn't work by attracting any response from Walter on most issues for quite a while. You'll need to get it past the shit-filters - that's all of us - before he'll even notice it; he's a busy man. ;)

In article <bvrvvn$31iu$1@digitaldaemon.com>, Ben Hinkle wrote:
> Interesting proposal - allow multiple inheritance of classes without fields.

If this is what was proposed in the original post, I'm all for it. (I couldn't quite understand what was actually suggested, but then again I'm tired and all that)

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

I'd prefer that the note in the D docs about multiple interfaces would be removed. Why explicitly ban a "feature" that does nothing? It's ok for me to still flag it as an error, because nobody will probably ever do it because it's, well, of no use (As Matthew, I think, pointed out.)

-Antti