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




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


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

 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


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

 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


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


 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

 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


only

 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


 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

 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

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


redundant.

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




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


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


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


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


:-)

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


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


:-)

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




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


 redundant.

 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




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


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


 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

 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