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

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

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

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

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

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

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

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

"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

> 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