www.digitalmars.com         C & C++   DMDScript  

D - Partial interface implementation

reply "Matthew" <matthew stlsoft.org> writes:
I know others have commented on this in recent weeks, but I want to add my
t'pen'th to the debate.

I want to be able to do the following:

interface IThing
{
public:
    void method1();
    void method2();
}

abstract class ThingImpl
    : IThing
{
public:
    void method2()
    {
    }
}

i.e., ThingImpl does not implement method1()
Apr 17 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Matthew" <matthew stlsoft.org> wrote in message
news:c5tarh$125t$1 digitaldaemon.com...
 I know others have commented on this in recent weeks, but I want to add my
 t'pen'th to the debate.

 I want to be able to do the following:

 interface IThing
 {
 public:
     void method1();
     void method2();
 }

 abstract class ThingImpl
     : IThing
 {
 public:
     void method2()
     {
     }
 }

 i.e., ThingImpl does not implement method1()

Can you please explain but i don't understand why would you wan't to do that? You can allways split IThing in 2 interfaces. If i write a function that takes IThing as an argument a wan't to know exactly what methods can be called. I would like to be able to write interface Isomething { static void method1(); } why this not possible? and doesn't even give any errors?
Apr 18 2004
parent reply "Matthew" <matthew stlsoft.org> writes:
I want it for the DTL.

Basically, I'm planning to have the container templates parameterisable,
such that one can use them in a way similar to C++'s (compile-time type
resolving) STL, or similar to .NET/Java's (runtime type resolving)
container/enumeration/collection interface-based approach.

This is requiring various changes to the language / compiler, and Walter and
I are working on all that at the moment.

Without going into the gorey, and currently daily-changing, details, the
behaviour I'd like would allow some of the adaptor classes for the runtime
type approach to be simpler.

However, I did find a workaround, which is simply to redeclare the
unimplemented interface method as an abstract method in the abstract class.
But even though I can see the upside of it, in being explicit in what's
going on at each level in the hierarchy, I don't like it. Maybe it's the C++
programmer in me, screaming to get out. ;)

"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:c5td9b$15e4$1 digitaldaemon.com...
 "Matthew" <matthew stlsoft.org> wrote in message
 news:c5tarh$125t$1 digitaldaemon.com...
 I know others have commented on this in recent weeks, but I want to add


 t'pen'th to the debate.

 I want to be able to do the following:

 interface IThing
 {
 public:
     void method1();
     void method2();
 }

 abstract class ThingImpl
     : IThing
 {
 public:
     void method2()
     {
     }
 }

 i.e., ThingImpl does not implement method1()

Can you please explain but i don't understand why would you wan't to do that? You can allways split IThing in 2 interfaces. If i write a function that takes IThing as an argument a wan't to know exactly what methods can be called. I would like to be able to write interface Isomething { static void method1(); } why this not possible? and doesn't even give any errors?

Apr 18 2004
next sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
Thanks for the answers. I can't wait for DTL!!!!! :)

"Matthew" <matthew stlsoft.org> wrote in message
news:c5thpl$1bj2$1 digitaldaemon.com...
 I want it for the DTL.

 Basically, I'm planning to have the container templates parameterisable,
 such that one can use them in a way similar to C++'s (compile-time type
 resolving) STL, or similar to .NET/Java's (runtime type resolving)
 container/enumeration/collection interface-based approach.

 This is requiring various changes to the language / compiler, and Walter

 I are working on all that at the moment.

 Without going into the gorey, and currently daily-changing, details, the
 behaviour I'd like would allow some of the adaptor classes for the runtime
 type approach to be simpler.

 However, I did find a workaround, which is simply to redeclare the
 unimplemented interface method as an abstract method in the abstract

 But even though I can see the upside of it, in being explicit in what's
 going on at each level in the hierarchy, I don't like it. Maybe it's the

 programmer in me, screaming to get out. ;)

 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 news:c5td9b$15e4$1 digitaldaemon.com...
 "Matthew" <matthew stlsoft.org> wrote in message
 news:c5tarh$125t$1 digitaldaemon.com...
 I know others have commented on this in recent weeks, but I want to



 my
 t'pen'th to the debate.

 I want to be able to do the following:

 interface IThing
 {
 public:
     void method1();
     void method2();
 }

 abstract class ThingImpl
     : IThing
 {
 public:
     void method2()
     {
     }
 }

 i.e., ThingImpl does not implement method1()

Can you please explain but i don't understand why would you wan't to do that? You can allways split IThing in 2 interfaces. If i write a function that takes IThing as an argument a wan't to know exactly what methods can be called. I would like to be able to write interface Isomething { static void method1(); } why this not possible? and doesn't even give any errors?


Apr 18 2004
prev sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
Ok, i forgot to reask (you probably know a lot about these things):
What about static functions in interfaces, i can't find my answer anywhere.
Maybe there are good reasons for not allowing static functions in interfaces
(but what are they?) but in that case declaring it that way should at least
be an error!

Do you know anything about this?

I really would like it :)



"Matthew" <matthew stlsoft.org> wrote in message
news:c5thpl$1bj2$1 digitaldaemon.com...
 I want it for the DTL.

 Basically, I'm planning to have the container templates parameterisable,
 such that one can use them in a way similar to C++'s (compile-time type
 resolving) STL, or similar to .NET/Java's (runtime type resolving)
 container/enumeration/collection interface-based approach.

 This is requiring various changes to the language / compiler, and Walter

 I are working on all that at the moment.

 Without going into the gorey, and currently daily-changing, details, the
 behaviour I'd like would allow some of the adaptor classes for the runtime
 type approach to be simpler.

 However, I did find a workaround, which is simply to redeclare the
 unimplemented interface method as an abstract method in the abstract

 But even though I can see the upside of it, in being explicit in what's
 going on at each level in the hierarchy, I don't like it. Maybe it's the

 programmer in me, screaming to get out. ;)

 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 news:c5td9b$15e4$1 digitaldaemon.com...
 "Matthew" <matthew stlsoft.org> wrote in message
 news:c5tarh$125t$1 digitaldaemon.com...
 I know others have commented on this in recent weeks, but I want to



 my
 t'pen'th to the debate.

 I want to be able to do the following:

 interface IThing
 {
 public:
     void method1();
     void method2();
 }

 abstract class ThingImpl
     : IThing
 {
 public:
     void method2()
     {
     }
 }

 i.e., ThingImpl does not implement method1()

Can you please explain but i don't understand why would you wan't to do that? You can allways split IThing in 2 interfaces. If i write a function that takes IThing as an argument a wan't to know exactly what methods can be called. I would like to be able to write interface Isomething { static void method1(); } why this not possible? and doesn't even give any errors?


Apr 18 2004
next sibling parent reply "Scott Egan" <scotte tpg.com.aux> writes:
Based on the idea of how interfaces work (nothing but a bunch of function
pointers), static functions would be impossible.

They may even be philosophically incompatible with interfaces - but I'm only
putting money on my first comment; philosophy isn't my strong point ;)

Regards,



"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:c5tq2d$1msv$1 digitaldaemon.com...
 Ok, i forgot to reask (you probably know a lot about these things):
 What about static functions in interfaces, i can't find my answer

 Maybe there are good reasons for not allowing static functions in

 (but what are they?) but in that case declaring it that way should at

 be an error!

 Do you know anything about this?

 I really would like it :)



 "Matthew" <matthew stlsoft.org> wrote in message
 news:c5thpl$1bj2$1 digitaldaemon.com...
 I want it for the DTL.

 Basically, I'm planning to have the container templates parameterisable,
 such that one can use them in a way similar to C++'s (compile-time type
 resolving) STL, or similar to .NET/Java's (runtime type resolving)
 container/enumeration/collection interface-based approach.

 This is requiring various changes to the language / compiler, and Walter

 I are working on all that at the moment.

 Without going into the gorey, and currently daily-changing, details, the
 behaviour I'd like would allow some of the adaptor classes for the


 type approach to be simpler.

 However, I did find a workaround, which is simply to redeclare the
 unimplemented interface method as an abstract method in the abstract

 But even though I can see the upside of it, in being explicit in what's
 going on at each level in the hierarchy, I don't like it. Maybe it's the

 programmer in me, screaming to get out. ;)

 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 news:c5td9b$15e4$1 digitaldaemon.com...
 "Matthew" <matthew stlsoft.org> wrote in message
 news:c5tarh$125t$1 digitaldaemon.com...
 I know others have commented on this in recent weeks, but I want to



 my
 t'pen'th to the debate.

 I want to be able to do the following:

 interface IThing
 {
 public:
     void method1();
     void method2();
 }

 abstract class ThingImpl
     : IThing
 {
 public:
     void method2()
     {
     }
 }

 i.e., ThingImpl does not implement method1()

Can you please explain but i don't understand why would you wan't to do that? You can allways split IThing in 2 interfaces. If i write a function that takes IThing as an argument a wan't to know exactly what methods can be called. I would like to be able to write interface Isomething { static void method1(); } why this not possible? and doesn't even give any errors?



Apr 18 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Scott Egan" <scotte tpg.com.aux> wrote in message
news:c5u2ad$236f$1 digitaldaemon.com...
 Based on the idea of how interfaces work (nothing but a bunch of function
 pointers), static functions would be impossible.

 They may even be philosophically incompatible with interfaces - but I'm

 putting money on my first comment; philosophy isn't my strong point ;)

 Regards,

There could also be a pointer to static function, couldn't there? The only difference would be the way they are called, for non-static you have to have an object, but static functions can only be called using a classes name (and why not an iterface name). I really hope that there aren't any strong philosophicall reasons for this not to work, because it would be a very useful feature. I miss it in one of my projects and it isn't even a big project, i think that the benefits of static interface functions would be great. In the case of this not being possible to implement a nice compiler message saying "interface function isn't allowed to be static!" would be very nice, because finding out that it doesn't work by means of strange linking errors isn't the best way. Hope Walter explained why this doesn't work, should it work, will it ever work? :) :)
 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 news:c5tq2d$1msv$1 digitaldaemon.com...
 Ok, i forgot to reask (you probably know a lot about these things):
 What about static functions in interfaces, i can't find my answer

 Maybe there are good reasons for not allowing static functions in

 (but what are they?) but in that case declaring it that way should at

 be an error!

 Do you know anything about this?

 I really would like it :)



 "Matthew" <matthew stlsoft.org> wrote in message
 news:c5thpl$1bj2$1 digitaldaemon.com...
 I want it for the DTL.

 Basically, I'm planning to have the container templates



 such that one can use them in a way similar to C++'s (compile-time



 resolving) STL, or similar to .NET/Java's (runtime type resolving)
 container/enumeration/collection interface-based approach.

 This is requiring various changes to the language / compiler, and



 and
 I are working on all that at the moment.

 Without going into the gorey, and currently daily-changing, details,



 behaviour I'd like would allow some of the adaptor classes for the


 type approach to be simpler.

 However, I did find a workaround, which is simply to redeclare the
 unimplemented interface method as an abstract method in the abstract

 But even though I can see the upside of it, in being explicit in



 going on at each level in the hierarchy, I don't like it. Maybe it's



 C++
 programmer in me, screaming to get out. ;)

 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 news:c5td9b$15e4$1 digitaldaemon.com...
 "Matthew" <matthew stlsoft.org> wrote in message
 news:c5tarh$125t$1 digitaldaemon.com...
 I know others have commented on this in recent weeks, but I want





 add
 my
 t'pen'th to the debate.

 I want to be able to do the following:

 interface IThing
 {
 public:
     void method1();
     void method2();
 }

 abstract class ThingImpl
     : IThing
 {
 public:
     void method2()
     {
     }
 }

 i.e., ThingImpl does not implement method1()

Can you please explain but i don't understand why would you wan't to do that? You can allways split IThing in 2 interfaces. If i write a function that takes IThing as an argument a wan't to




 exactly what methods can be called.

 I would like to be able to write
 interface Isomething
 {
     static void method1();
 }
 why this not possible? and doesn't even give any errors?




Apr 18 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Ivan Senji schrieb:
 There could also be a pointer to static function, couldn't there?
 The only difference would be the way they are called, for non-static
 you have to have an object, but static functions can only be called
 using a classes name (and why not an iterface name).

A static function can also be called using object's name, it just may not do anything with "this". No, i don't see a technical reason, but implementation may be more complex because it would interfere with current objects probably not carrying around their statics in the VTable.
 I really hope that there aren't any strong philosophicall reasons
 for this not to work, because it would be a very useful feature.

Not really strong, but if you think of it, statics are functions which don't depend on a certain object, but are only put in its namespace. What would that yuild for interfaces? Like, if it can only be called as InterfaceName.member() is obvious and doesn't reqiere VTable, but it's probably not what you mean?
 I miss it in one of my projects and it isn't even a big project,
 i think that the benefits of static interface functions would be great.

Could you please explain the situation you have? It usually helps if Walter can see usage cases, because static interface members seem redundant.
 In the case of this not being possible to implement a nice compiler message
 saying "interface function isn't allowed to be static!" would be very nice,
 because finding out that it doesn't work by means of strange linking errors
 isn't the best way.

It looks like simply Walter has not decided how to deal with this case.
 Hope Walter explained why this doesn't work, should it work, will it ever
 work?
 :) :)

We're waiting for him. -eye
Apr 18 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:c5uf6v$2mqf$1 digitaldaemon.com...
 Ivan Senji schrieb:
 There could also be a pointer to static function, couldn't there?
 The only difference would be the way they are called, for non-static
 you have to have an object, but static functions can only be called
 using a classes name (and why not an iterface name).

A static function can also be called using object's name, it just may not do anything with "this". No, i don't see a technical reason, but implementation may be more complex because it would interfere with current objects probably not carrying around their statics in the VTable.

Ups I forgot static member functions can be called on objects :)
 I really hope that there aren't any strong philosophicall reasons
 for this not to work, because it would be a very useful feature.

Not really strong, but if you think of it, statics are functions which don't depend on a certain object, but are only put in its namespace. What would that yuild for interfaces? Like, if it can only be called as InterfaceName.member() is obvious and doesn't reqiere VTable, but it's probably not what you mean?

Static functions of a class have something to do with that type. InterfaceName.member() is what i wan't (where member is static).
 I miss it in one of my projects and it isn't even a big project,
 i think that the benefits of static interface functions would be great.

Could you please explain the situation you have? It usually helps if Walter can see usage cases, because static interface members seem

I have a parser that takes for input ILexElement[] and this interface requires a class that implements it to implement some functionality. But at one moment when the parser is building a parse tree i need to create the a new object of the type that implements ILexElement. But the Parser class only knows it is ILexElement so the solution i wanted to try was to add a static function create to the interface interface ILexElement { static ILexElement create(char[] name); } And this would be a great, simple and elegant solution. Can yout think of another one better?
 In the case of this not being possible to implement a nice compiler


 saying "interface function isn't allowed to be static!" would be very


 because finding out that it doesn't work by means of strange linking


 isn't the best way.

It looks like simply Walter has not decided how to deal with this case.
 Hope Walter explained why this doesn't work, should it work, will it


 work?
 :) :)

We're waiting for him. -eye

Apr 18 2004
next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
 But the Parser class only knows it is ILexElement so the solution
 i wanted to try was to add a static function create to the interface
 interface ILexElement
 {
     static ILexElement create(char[] name);
 }
 And this would be a great, simple and elegant solution.
 Can yout think of another one better?

Why make it static? You're asking the ILexElement implementation to create an instance of itself, which should be implementation specific. Even if there was only a single concrete implementation of the Interface, it would surely be considered good practice to permit the factory method to be overloaded. - Kris
Apr 18 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c5usik$8it$1 digitaldaemon.com...
 But the Parser class only knows it is ILexElement so the solution
 i wanted to try was to add a static function create to the interface
 interface ILexElement
 {
     static ILexElement create(char[] name);
 }
 And this would be a great, simple and elegant solution.
 Can yout think of another one better?

Why make it static? You're asking the ILexElement implementation to create an instance of itself, which should be implementation specific. Even if there was only a single concrete implementation of the Interface, it would surely be considered good practice to permit the factory method to be overloaded.

I'm sorry but i don't understand what you mean. :) I really am asking ILexElement (actually the class implementing it) to create an instance of itself. Is there anything wrong with that? And naturally it is implementation specific, my classes only requirement is that its argument is of type ILexElement and this means that it should implement some methods my class uses. The current solution i use is to make this create method nonstatic but there is a problem that i allways need to have an instance of the object to call that one. But what if i don't have an instance? Maybe i could try to have that type like a template argument, but i think that the solution with the interface would be simpler, and it would clearly state what are the requirements to the class that is implementing it.
Apr 18 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:c5v0b4$ecq$1 digitaldaemon.com...
 "Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
 news:c5usik$8it$1 digitaldaemon.com...
 I really am asking ILexElement (actually the class implementing it) to
 create an instance of itself. Is there anything wrong with that?

No, not at all :-)
 The current solution i use is to make this create method
 nonstatic but there is a problem that i allways need to
 have an instance of the object to call that one. But what if i
 don't have an instance?

Therein lies the rub. How about providing a Singleton, for use in constructing ILexElement instances? For example, you might perhaps have a static instance of the ILexElement implementation available for construction purposes ... That may not be ideal in your particular case, but is fairly typical of the Factory-Pattern approach. Just for clarity, here's an example: interface I { I create(); } class Foo : I { I create() { return new Foo(); } } static I factory; static this() { factory = new Foo(); } void parser() { I i = factory.create(); }
Apr 18 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c5v3rf$j7v$1 digitaldaemon.com...
 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 news:c5v0b4$ecq$1 digitaldaemon.com...
 "Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
 news:c5usik$8it$1 digitaldaemon.com...
 I really am asking ILexElement (actually the class implementing it) to
 create an instance of itself. Is there anything wrong with that?

No, not at all :-)
 The current solution i use is to make this create method
 nonstatic but there is a problem that i allways need to
 have an instance of the object to call that one. But what if i
 don't have an instance?

Therein lies the rub. How about providing a Singleton, for use in constructing ILexElement instances? For example, you might perhaps have a static instance of the ILexElement implementation available for

 purposes ...

 That may not be ideal in your particular case, but is fairly typical of

 Factory-Pattern approach.

 Just for clarity, here's an example:

 interface I
 {
     I create();
 }

 class Foo : I
 {
     I create()
     {
         return new Foo();
     }
 }

 static I  factory;

 static this()
 {
     factory = new Foo();
 }

 void parser()
 {
        I i = factory.create();
 }

Thanks, probably i will go with curent solution with using the instantiated object. When i woke up today it came to me why compiler might not know how to use static methods in interfaces. The reason is that when i write IInterfaceName.staticMethodName() there could be more classes implementing this interface so there is no way for compiler to know wich classes static method am i trying to call! I am sorry to have wasted all yours preacious time but it seamed for a while like it would be a nice thing to have. Now that i know it is imposible i will finally give it up :)
Apr 19 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 When i woke up today it came to me why compiler might not know
 how to use static methods in interfaces.

OT: Isn't the Web truly great? ... someone is always waking up at around the same time one might be thinking of getting some sleep; yet the web makes it *convenient* to be engaged in a spontaneous discussion. That's progress :-)
Apr 19 2004
next sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c5vv7i$1u0b$1 digitaldaemon.com...
 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 When i woke up today it came to me why compiler might not know
 how to use static methods in interfaces.

OT: Isn't the Web truly great? ... someone is always waking up at around

 same time one might be thinking of getting some sleep; yet the web makes

 *convenient* to be engaged in a spontaneous discussion. That's progress

That really is great!!
Apr 19 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c5vv7i$1u0b$1 digitaldaemon.com...
 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 When i woke up today it came to me why compiler might not know
 how to use static methods in interfaces.

OT: Isn't the Web truly great? ... someone is always waking up at around

 same time one might be thinking of getting some sleep; yet the web makes

 *convenient* to be engaged in a spontaneous discussion. That's progress

It is fab. I had reviewers for "Imperfect C++" from all over the world, most of whom I've never met in person. Yet they were prepared to devote their valuable time to the project, and the book is immeasurably better for it. It's amazing how this technology brings us all together. Now if only we could get a few political figures to MSN each other, instead of ...
Apr 20 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
Ah, I think I see where you're coming from.

In which case I disagree with the intent.

For me, static interface methods are only useful in structural conformance
(e.g. an overload with fewer members, calling the virtual interface method),
not in doing virtual construction, or any other wacky stuff.

Sorry. :(

"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:c5upp0$4l7$1 digitaldaemon.com...
 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:c5uf6v$2mqf$1 digitaldaemon.com...
 Ivan Senji schrieb:
 There could also be a pointer to static function, couldn't there?
 The only difference would be the way they are called, for non-static
 you have to have an object, but static functions can only be called
 using a classes name (and why not an iterface name).

A static function can also be called using object's name, it just may not do anything with "this". No, i don't see a technical reason, but implementation may be more complex because it would interfere with current objects probably not carrying around their statics in the


 Ups I forgot static member functions can be called on objects :)

 I really hope that there aren't any strong philosophicall reasons
 for this not to work, because it would be a very useful feature.

Not really strong, but if you think of it, statics are functions which don't depend on a certain object, but are only put in its namespace. What would that yuild for interfaces? Like, if it can only be called as InterfaceName.member() is obvious and doesn't reqiere VTable, but it's probably not what you mean?

Static functions of a class have something to do with that type. InterfaceName.member() is what i wan't (where member is static).
 I miss it in one of my projects and it isn't even a big project,
 i think that the benefits of static interface functions would be



 Could you please explain the situation you have? It usually helps if
 Walter can see usage cases, because static interface members seem

I have a parser that takes for input ILexElement[] and this interface requires a class that implements it to implement some functionality. But at one moment when the parser is building a parse tree i need to create the a new object of the type that implements ILexElement. But the Parser class only knows it is ILexElement so the solution i wanted to try was to add a static function create to the interface interface ILexElement { static ILexElement create(char[] name); } And this would be a great, simple and elegant solution. Can yout think of another one better?
 In the case of this not being possible to implement a nice compiler


 saying "interface function isn't allowed to be static!" would be very


 because finding out that it doesn't work by means of strange linking


 isn't the best way.

It looks like simply Walter has not decided how to deal with this case.
 Hope Walter explained why this doesn't work, should it work, will it


 work?
 :) :)

We're waiting for him. -eye


Apr 20 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
I'm not sure. I make use of them in C++, say to add an overload to a C/C++
interface for C++ compilation, but I'm not sure they're appropriate in D.

There's no technical reason why they should not be included, since they do
not, by definition, interfere with the vtable. However, I think there may be
conceptual objections. For example, what if two interfaces provide the same
static method. We cannot use method colouring - is that the right term? I'm
still jetlagged - since they are not virtual.

"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:c5tq2d$1msv$1 digitaldaemon.com...
 Ok, i forgot to reask (you probably know a lot about these things):
 What about static functions in interfaces, i can't find my answer

 Maybe there are good reasons for not allowing static functions in

 (but what are they?) but in that case declaring it that way should at

 be an error!

 Do you know anything about this?

 I really would like it :)



 "Matthew" <matthew stlsoft.org> wrote in message
 news:c5thpl$1bj2$1 digitaldaemon.com...
 I want it for the DTL.

 Basically, I'm planning to have the container templates parameterisable,
 such that one can use them in a way similar to C++'s (compile-time type
 resolving) STL, or similar to .NET/Java's (runtime type resolving)
 container/enumeration/collection interface-based approach.

 This is requiring various changes to the language / compiler, and Walter

 I are working on all that at the moment.

 Without going into the gorey, and currently daily-changing, details, the
 behaviour I'd like would allow some of the adaptor classes for the


 type approach to be simpler.

 However, I did find a workaround, which is simply to redeclare the
 unimplemented interface method as an abstract method in the abstract

 But even though I can see the upside of it, in being explicit in what's
 going on at each level in the hierarchy, I don't like it. Maybe it's the

 programmer in me, screaming to get out. ;)

 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 news:c5td9b$15e4$1 digitaldaemon.com...
 "Matthew" <matthew stlsoft.org> wrote in message
 news:c5tarh$125t$1 digitaldaemon.com...
 I know others have commented on this in recent weeks, but I want to



 my
 t'pen'th to the debate.

 I want to be able to do the following:

 interface IThing
 {
 public:
     void method1();
     void method2();
 }

 abstract class ThingImpl
     : IThing
 {
 public:
     void method2()
     {
     }
 }

 i.e., ThingImpl does not implement method1()

Can you please explain but i don't understand why would you wan't to do that? You can allways split IThing in 2 interfaces. If i write a function that takes IThing as an argument a wan't to know exactly what methods can be called. I would like to be able to write interface Isomething { static void method1(); } why this not possible? and doesn't even give any errors?



Apr 20 2004