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

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

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

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

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

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

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

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