www.digitalmars.com         C & C++   DMDScript  

D - [BUG] yet another interface related issue

reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
I'm sure many of you are sick to death of hearing about Interface related
flaws and bugs: personally, I'm thoroughly fed up of running into them. This
one is another doozy ...

OK; so we have a extensible Tokenizer subsystem. It scans input for
delimited content and places the results in a Token. Here's a stripped-down
version of the participants:

class Token
{
    private char[] value;

    void setValue (char[] value)
    {
       this.value = value;
    }
}

class Tokenizer
{
    abstract bool next (Token token);

    // other base-class stuff here
}

class LineTokenizer : Tokenizer
{
    bool next (Token token)
    {
    // do some stuff

    // set Token content
    token.setValue (....);
    }
}

There are a variety of Tokenizer derivatives that handle different scanning
flavours. We can specialize with a SpaceTokenizer, CommaTokenizer,
RegexTokenizer, and so on. They all operate upon the basic Token class.

Now, we wish to introduce a *slightly* more sophisticated Token derivative
called CookieToken:

class CookieToken : Token
{
    private char[] name;

    void setName (char[] name)
    {
        this.name = name;
    }
}

... and we want to pass it to a CookieTokenizer:

class CookieTokenizer : Tokenizer
{
    bool next (CookieToken token)
    {
    // do some stuff

    // set Token content
    token.setValue (....);
    token.setName (...);
    }
}

Note how the abstract method next() should accept a CookieToken rather than
the basic Token?

So, the compiler says (and I quote)  "No wayyy pal. CookieTokenizer is now
one o' them abstract-classes cos' yer method signatures cannae be matched".

OK. Fair enough, Mr Compiler. This is where the power of Interfaces is
typically brought to bear: one would simply "virtualize" the basic Token
class with an IToken interface.

"All ABOARD!".   Here we go now ...

// define interface
interface IToken
{
   void setValue (char[]);
}

// specify that our Token implements the IToken interface
class Token : IToken
{
   void setValue (char[]);
}

// update Tokenizer base-class with the Interface
class Tokenizer
{
    abstract bool next (IToken token);

    // other base-class stuff here
}

// update LineTokenizer with the Interface
class LineTokenizer : Tokenizer
{
    bool next (IToken token)
    {
    // do some stuff

    // set Token content
    token.setValue (....);
    }
}

So far so good.  Now we should be able to pass our CookieToken to the next()
method because it is an *instance* of the IToken Interface. This concept  is
a fundamental of contractual-specification support that an OO Interface
exposes:

class CookieTokenizer : Tokenizer
{
    bool next (CookieToken token)
    {
    // do some stuff

    // set Token content
    token.setValue (....);
    token.setName (...);
    }
}

Hey Presto!

Whoops! Compiler says "Oan yer bike pally! Ahh don't care a wee flying *&%#
if yer CookieToken is an IToken instance or no!"

Well, what can one say to that?  Actually, I can think of a few choice
phrases ...

This is Interfaces 101, people. It doesn't even pass the sniff test. One
might confidently state that the method-matching algorithm has absolutely no
concept of Interfaces.

You might think one could use a base-class instead right? Well,
unfortunately, that didn't work in the first instance (before the Interface
attempt). Apparently, D simply does not grok the concept of passing derived
objects as an argument via a base-class. Let alone Interfaces. Can anyone
say "polymorphic meltdown" ?

Sigh. Double Sigh.  Any ideas? Suggestions? Resolutions? Should I just give
up?

- Kris
Apr 06 2004
next sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
I'm not shure that i know exactly what the problem is,but can you not do
this:
class CookieTokenizer : Tokenizer
{
    bool next (IToken token)
    {
    // do some stuff

    // set Token content
    token.setValue (....);
    token.setName (...);
    }
}

Then CookieTokenizer can take as an argument CookieToken because it
implements IToken
but it can't be cast to CookieToken to use it's specific properties?

My plan was for these days to convert a parser i am writing in D to a
version thet doesnt just take an argument
of type char[][] but it can take an argument of type ILexicalElement,
then the user implements ILexicalElement in his class and can,
call my parser but what happens when i want to return to the user
ILexicalElement (for example i return the one that coused a parsing error)
and the user cant cast it back to his (MyLexElement) type to get some
extra information?

If i understand the problems with D interfaces i will have to wait before
i convert my project to interfaces-version :(


"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c505g4$1n6f$1 digitaldaemon.com...
 I'm sure many of you are sick to death of hearing about Interface related
 flaws and bugs: personally, I'm thoroughly fed up of running into them.

 one is another doozy ...

 OK; so we have a extensible Tokenizer subsystem. It scans input for
 delimited content and places the results in a Token. Here's a

 version of the participants:

 class Token
 {
     private char[] value;

     void setValue (char[] value)
     {
        this.value = value;
     }
 }

 class Tokenizer
 {
     abstract bool next (Token token);

     // other base-class stuff here
 }

 class LineTokenizer : Tokenizer
 {
     bool next (Token token)
     {
     // do some stuff

     // set Token content
     token.setValue (....);
     }
 }

 There are a variety of Tokenizer derivatives that handle different

 flavours. We can specialize with a SpaceTokenizer, CommaTokenizer,
 RegexTokenizer, and so on. They all operate upon the basic Token class.

 Now, we wish to introduce a *slightly* more sophisticated Token derivative
 called CookieToken:

 class CookieToken : Token
 {
     private char[] name;

     void setName (char[] name)
     {
         this.name = name;
     }
 }

 ... and we want to pass it to a CookieTokenizer:

 class CookieTokenizer : Tokenizer
 {
     bool next (CookieToken token)
     {
     // do some stuff

     // set Token content
     token.setValue (....);
     token.setName (...);
     }
 }

 Note how the abstract method next() should accept a CookieToken rather

 the basic Token?

 So, the compiler says (and I quote)  "No wayyy pal. CookieTokenizer is now
 one o' them abstract-classes cos' yer method signatures cannae be

 OK. Fair enough, Mr Compiler. This is where the power of Interfaces is
 typically brought to bear: one would simply "virtualize" the basic Token
 class with an IToken interface.

 "All ABOARD!".   Here we go now ...

 // define interface
 interface IToken
 {
    void setValue (char[]);
 }

 // specify that our Token implements the IToken interface
 class Token : IToken
 {
    void setValue (char[]);
 }

 // update Tokenizer base-class with the Interface
 class Tokenizer
 {
     abstract bool next (IToken token);

     // other base-class stuff here
 }

 // update LineTokenizer with the Interface
 class LineTokenizer : Tokenizer
 {
     bool next (IToken token)
     {
     // do some stuff

     // set Token content
     token.setValue (....);
     }
 }

 So far so good.  Now we should be able to pass our CookieToken to the

 method because it is an *instance* of the IToken Interface. This concept

 a fundamental of contractual-specification support that an OO Interface
 exposes:

 class CookieTokenizer : Tokenizer
 {
     bool next (CookieToken token)
     {
     // do some stuff

     // set Token content
     token.setValue (....);
     token.setName (...);
     }
 }

 Hey Presto!

 Whoops! Compiler says "Oan yer bike pally! Ahh don't care a wee flying

 if yer CookieToken is an IToken instance or no!"

 Well, what can one say to that?  Actually, I can think of a few choice
 phrases ...

 This is Interfaces 101, people. It doesn't even pass the sniff test. One
 might confidently state that the method-matching algorithm has absolutely

 concept of Interfaces.

 You might think one could use a base-class instead right? Well,
 unfortunately, that didn't work in the first instance (before the

 attempt). Apparently, D simply does not grok the concept of passing

 objects as an argument via a base-class. Let alone Interfaces. Can anyone
 say "polymorphic meltdown" ?

 Sigh. Double Sigh.  Any ideas? Suggestions? Resolutions? Should I just

 up?

 - Kris

Apr 07 2004
parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:c508u1$1sbm$1 digitaldaemon.com...
 Then CookieTokenizer can take as an argument CookieToken because it
 implements IToken
 but it can't be cast to CookieToken to use it's specific properties?

Yes, one could use an upcast inside the next() method (that's just what I'm doing to keep momentum going). But there's at least five problems with that approach Ivan: 1) it totally abandons the inutuitive, expressive, and bug-eliminating approach that Interfaces were designed to help one avoid. That is, D does not support some of the most basic Interface fundamentals (and arguably some OO fundamentals). 2) It's counter-intuitive. One of the stated goals for D was, and is, "ease of use". The required use of upcasts to handle even this trivial design is so far off base ... I don't even know where to begin. 3) Cast should be avoided as much as possible, so as the compiler can tell you when you're doing something wrong. This is especially true for non-expert users. Again, Interfaces were designed to alleviate this. 4) the upcast would be a dynamic_cast. That's not a trivial piece of code to execute (it has a loop), so there are performance implications that could easily be avoided with the correct semantic support. 5) And perhaps worst of all: If, as you suggest, one were to upcast the IToken argument, the D compiler will silently emit bogus code into your executable such that it will deliberately cause an access-violation at runtime (in place of the upcast). According to recent public record, this is per design. The compiler is not expected to issue an error. Again, I just don't know what to say about that.
 and the user cant cast it back to his (MyLexElement) type to get some
 extra information?

As it stands, you cannot cast() an interface back to a concrete object. The compiler emits code to cause ... well, we know what it does. You can revert to an arcane "decoration" approach, whereby your interface (and Object) exposes a method with this pattern: Object toObject() {return this;} Once you get the Interface converted to a real Object, you can then upcast it, using the slow dynamic_cast. Once again, this is not exactly what I'd refer to as "ease of use". Oh well; perhaps some good will come out of this farce :-( - Kris
Apr 07 2004
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
 // update LineTokenizer with the Interface
 class LineTokenizer : Tokenizer
 {
     bool next (IToken token)
     {
     // do some stuff

     // set Token content
     token.setValue (....);
     }
 }

 So far so good.  Now we should be able to pass our CookieToken to the

 method because it is an *instance* of the IToken Interface. This concept

 a fundamental of contractual-specification support that an OO Interface
 exposes:

 class CookieTokenizer : Tokenizer
 {
     bool next (CookieToken token)
     {
     // do some stuff

     // set Token content
     token.setValue (....);
     token.setName (...);
     }
 }

Were you expecting the bool next(CookitToken token) to override bool next(IToken token) If so I don't agree it should override. It is a very different signature. Overload, sure, but not override. Then again, maybe I don't understand your question. -Ben
Apr 07 2004
next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
Having to perform an upcast for such a trivial design is, in my opinion, a
failure at the language level, Ben; particularly so when cast() on an
Interface deliberately barfs at runtime.

And I suppose that post is really not a question, but a rant. Perhaps I'm
Overloaded with frustration on what appears to be a zero level of commitment
on Walter's part to even consider fixing the Interface travesty. Rather, the
few responses (to posts by myself and others) have been laced with denial.

Trying hard to get these three projects completed (in support of D, I might
add), yet there's precious little in the way of "OK, let's take a serious
look at these issues".  It really seems as though every turn in the road
vis-a-vis Interfaces is met with a metaphorical stonewall.

On Reflection, I sound pissed-off.  I should probably just back away;

- Kris


"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:c50vlp$2ves$1 digitaldaemon.com...
 // update LineTokenizer with the Interface
 class LineTokenizer : Tokenizer
 {
     bool next (IToken token)
     {
     // do some stuff

     // set Token content
     token.setValue (....);
     }
 }

 So far so good.  Now we should be able to pass our CookieToken to the

 method because it is an *instance* of the IToken Interface. This concept

 a fundamental of contractual-specification support that an OO Interface
 exposes:

 class CookieTokenizer : Tokenizer
 {
     bool next (CookieToken token)
     {
     // do some stuff

     // set Token content
     token.setValue (....);
     token.setName (...);
     }
 }

Were you expecting the bool next(CookitToken token) to override bool next(IToken token) If so I don't agree it should override. It is a very different signature. Overload, sure, but not override. Then again, maybe I don't understand your question. -Ben

Apr 07 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <c51k9i$tqm$1 digitaldaemon.com>, Kris says...
Having to perform an upcast for such a trivial design is, in my opinion, a
failure at the language level, Ben; particularly so when cast() on an
Interface deliberately barfs at runtime.

And I suppose that post is really not a question, but a rant. Perhaps I'm
Overloaded with frustration on what appears to be a zero level of commitment
on Walter's part to even consider fixing the Interface travesty.

Walter tends to say things only once. but sometimes he says a different thing on the change log of the new release! He might even responde directly to you and all we others will be left on the dark... Ant
Apr 07 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
Thanks, Antonio.

I'll be sure to let you know (personally) if it's the latter <g>


"Ant" <Ant_member pathlink.com> wrote in message
news:c51m6l$10j9$1 digitaldaemon.com...
 In article <c51k9i$tqm$1 digitaldaemon.com>, Kris says...
Having to perform an upcast for such a trivial design is, in my opinion,


failure at the language level, Ben; particularly so when cast() on an
Interface deliberately barfs at runtime.

And I suppose that post is really not a question, but a rant. Perhaps I'm
Overloaded with frustration on what appears to be a zero level of


on Walter's part to even consider fixing the Interface travesty.

Walter tends to say things only once. but sometimes he says a different thing on the change log of the new release! He might even responde directly to you and all we others will be left on the dark... Ant

Apr 07 2004
parent reply C <dont respond.com> writes:
Yea hes notoriously non-commital , but the changes usually find there wa=
y =

in there.  (Could you let me know also pls ? , preciate it :) )

C

On Wed, 7 Apr 2004 12:06:34 -0800, Kris =

<someidiot earthlink.dot.dot.dot.net> wrote:

 Thanks, Antonio.

 I'll be sure to let you know (personally) if it's the latter <g>


 "Ant" <Ant_member pathlink.com> wrote in message
 news:c51m6l$10j9$1 digitaldaemon.com...
 In article <c51k9i$tqm$1 digitaldaemon.com>, Kris says...
Having to perform an upcast for such a trivial design is, in my =



 opinion,

failure at the language level, Ben; particularly so when cast() on a=



Interface deliberately barfs at runtime.

And I suppose that post is really not a question, but a rant. Perhap=



 I'm
Overloaded with frustration on what appears to be a zero level of


on Walter's part to even consider fixing the Interface travesty.

Walter tends to say things only once. but sometimes he says a different thing on the change log of the new release! He might even responde directly to you and all we others will be left on the dark... Ant


-- = D Newsgroup.
Apr 07 2004
parent reply "Phill" <phill pacific.net.au> writes:
"C" <dont respond.com> wrote in message news:opr53xjdptehmtou localhost...
Yea hes notoriously non-commital , but the changes usually find there way
in there.  (Could you let me know also pls ? , preciate it :) )

Me too please ??

Hey, I got a great idea, why dont you post it
so we can all know?

Phill.


C

On Wed, 7 Apr 2004 12:06:34 -0800, Kris
<someidiot earthlink.dot.dot.dot.net> wrote:

 Thanks, Antonio.

 I'll be sure to let you know (personally) if it's the latter <g>


 "Ant" <Ant_member pathlink.com> wrote in message
 news:c51m6l$10j9$1 digitaldaemon.com...
 In article <c51k9i$tqm$1 digitaldaemon.com>, Kris says...
Having to perform an upcast for such a trivial design is, in my


failure at the language level, Ben; particularly so when cast() on an
Interface deliberately barfs at runtime.

And I suppose that post is really not a question, but a rant. Perhaps

Overloaded with frustration on what appears to be a zero level of


on Walter's part to even consider fixing the Interface travesty.

Walter tends to say things only once. but sometimes he says a different thing on the change log of the new release! He might even responde directly to you and all we others will be left on the dark... Ant


-- D Newsgroup. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.648 / Virus Database: 415 - Release Date: 3/31/2004
Apr 08 2004
parent John Reimer <jjreimer telus.net> writes:
Phill wrote:

 
 "C" <dont respond.com> wrote in message news:opr53xjdptehmtou localhost...
 Yea hes notoriously non-commital , but the changes usually find there way
 in there.  (Could you let me know also pls ? , preciate it :) )
 
 Me too please ??
 
 Hey, I got a great idea, why dont you post it
 so we can all know?
 
 Phill.

You know what? That just sounds wrong. If Walter is conversing through private email with somebody, then the content of the email is usually intended to stay private. Wouldn't Walter post these things here if he really wanted to? The polite thing would be to leave these announcements for Walter to post. I have no doubt that he would announce these things at the appropriate time. Announcing it early before a fix is even publicly released would just get everybody overly excited and impatient. my 100 dollars :-), John
Apr 08 2004
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
About the whole upcasting thing...
implementing a "Castable" interface isn't too bad:

version = castable;

interface Castable {
  Object object();
}

// any interface that wants to be castable should extend Castable
interface IFoo : Castable {
  void foo();
}

// sample class implementing a castable interface
class Foo: IFoo {
  void foo() { print();} // IFoo
  Object object(){ return this; } // Castable
}

// sample function that takes a castable interface
void bar(IFoo x)
{
  Foo y;
  version(castable) {
    y = cast(Foo)x.object; // "cast" using .object
  } else {
    y = cast(Foo)x; // regular casts return null
  }
  y.print();
}

int
main()
{
  bar(new Foo());
  return 0;
}
Apr 07 2004
next sibling parent reply John Reimer <jjreimer telus.net> writes:
Ben Hinkle wrote:
 About the whole upcasting thing...
 implementing a "Castable" interface isn't too bad:
 

Very interesting! I've been following these interface threads with growing consternation over the issues (Kris has a nasty habit of painting rather clear pictures ... bad, Kris, bad, bad, bad... you're too good at infecting people with dismay). It's nice to see some relatively "smooth" solutions in the meantime (versus ugly "hacks"). I wonder how comprehensive a solution this could be until the interface features in D can be fixed. :-) Later, John
Apr 07 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
You're a comedian John <g>

 relatively "smooth" solutions in the meantime (versus ugly "hacks").  I
 wonder how comprehensive a solution this could be until the interface
 features in D can be fixed.

Ben's suggestion is certainly fair. There are other vaguely similar solutions scattered throughout three different threads, yet all fall apart when testing one Interface against another. BTW, I am actually using what Ben has suggested as a workaround in Dsc.io alpha_6, which you should have received on Monday. Take a look at IConduit.d, and other related classes (Conduit.d, Socket.d, AbstractServer.d). - Kris (Hope you're feeling better ...) "John Reimer" <jjreimer telus.net> wrote in message news:c51rof$191s$1 digitaldaemon.com...
 Ben Hinkle wrote:
 About the whole upcasting thing...
 implementing a "Castable" interface isn't too bad:

Very interesting! I've been following these interface threads with growing consternation over the issues (Kris has a nasty habit of painting rather clear pictures ... bad, Kris, bad, bad, bad... you're too good at infecting people with dismay). It's nice to see some relatively "smooth" solutions in the meantime (versus ugly "hacks"). I wonder how comprehensive a solution this could be until the interface features in D can be fixed. :-) Later, John

Apr 07 2004
parent John Reimer <jjreimer telus.net> writes:
Kris wrote:
 You're a comedian John <g>

Sometimes overdone... Forgive me!
 
relatively "smooth" solutions in the meantime (versus ugly "hacks").  I
wonder how comprehensive a solution this could be until the interface
features in D can be fixed.

Ben's suggestion is certainly fair. There are other vaguely similar solutions scattered throughout three different threads, yet all fall apart when testing one Interface against another.

Well, I figured that none of these solutions could be absolutely foolproof. Workarounds rarely are.
 BTW, I am actually using what Ben has suggested as a workaround in Dsc.io
 alpha_6, which you should have received on Monday. Take a look at
 IConduit.d, and other related classes (Conduit.d, Socket.d,
 AbstractServer.d).

Argh! I was wondering how you fixed it up. I hadn't quite got around to looking at alpha_6 internals. Shame on me!
 - Kris
 
 (Hope you're feeling better ...)
 

Oh, I'm getting there. Thanks.
Apr 07 2004
prev sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
On the face of it, that really doesn't seem so bad. It's when you dig a bit
deeper that this house-of-cards start to fall apart.

For example: I have a couple of Interfaces, IReadable and IWritable that are
applied by a developer to any class they wish to "bind" into the Dsc.io
environment. These interfaces are deliberately one method only, so as to
impinge as little as possible on the developer. Should they have to
implement some vague toObject() as well, just because COM support supposedly
demotes Interface to a third-class citizen?

That one is a stylistic issue. On perhaps a more practical note, I have
reason to require testing whether an Interface (contract) is also an
instance of another Interface (contract): in just the same manner as one
sometimes tests plain old Object pairs. In such cases, both Interfaces would
have to be "objectized" first (via toObject()) so they could be cast
compared, but then they are now both Object instances and will test
equivalent as such. They've lost their original type via the downcast <g>

Walter had originally suggested placing a to[Type]() object in each
interface, which would retain the original type. However, that's simply
unrealistic because (a) each interface would thus need to be pre-configured
with every concrete object-type that would ever choose to implement said
interface, and (b) it explicitly binds the Interface to
concrete-implementation, which then requires every single bit of that code
be available just to compile said Interface <g>

So, not only is toObject() somewhat arcane, it falls apart rather quickly.
Part of my beef with all this Ben, is the "ease of use" concern. D *should*
be easy to learn and use. That's a huge factor in the commercial-sector
where learning difficulties are magnified/multiplied by the number of
developers

Does this make any sense?

- Kris


"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:c51q1d$16ck$1 digitaldaemon.com...
 About the whole upcasting thing...
 implementing a "Castable" interface isn't too bad:

 version = castable;

 interface Castable {
   Object object();
 }

 // any interface that wants to be castable should extend Castable
 interface IFoo : Castable {
   void foo();
 }

 // sample class implementing a castable interface
 class Foo: IFoo {
   void foo() { print();} // IFoo
   Object object(){ return this; } // Castable
 }

 // sample function that takes a castable interface
 void bar(IFoo x)
 {
   Foo y;
   version(castable) {
     y = cast(Foo)x.object; // "cast" using .object
   } else {
     y = cast(Foo)x; // regular casts return null
   }
   y.print();
 }

 int
 main()
 {
   bar(new Foo());
   return 0;
 }

Apr 07 2004
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
It's pretty rare when Walter actually ignores us.  But he often lurks, 
probably so he can spend his time actually doing real coding work :)

More often than not, when we bring up these sorts of problems, we see 
them fixed a few versions later...even if the first notice of his work 
is in the Changelog.  Take a look at prior discussions about 
templates/generics, delegates, etc.

My counsel is to have patience.

Kris wrote:
 Having to perform an upcast for such a trivial design is, in my opinion, a
 failure at the language level, Ben; particularly so when cast() on an
 Interface deliberately barfs at runtime.
 
 And I suppose that post is really not a question, but a rant. Perhaps I'm
 Overloaded with frustration on what appears to be a zero level of commitment
 on Walter's part to even consider fixing the Interface travesty. Rather, the
 few responses (to posts by myself and others) have been laced with denial.
 
 Trying hard to get these three projects completed (in support of D, I might
 add), yet there's precious little in the way of "OK, let's take a serious
 look at these issues".  It really seems as though every turn in the road
 vis-a-vis Interfaces is met with a metaphorical stonewall.
 
 On Reflection, I sound pissed-off.  I should probably just back away;

Apr 08 2004
prev sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:c50vlp$2ves$1 digitaldaemon.com...
 Were you expecting the
  bool next(CookitToken token)
 to override
  bool next(IToken token)
 If so I don't agree it should override. It is a very different signature.
 Overload, sure, but not override.
 Then again, maybe I don't understand your question.

 -Ben

You are, of course, absolutely right Ben. With respect to the title-post of this thread, I must offer a humble and profound apology for wasting everyone's time and bandwidth over what was a gross error on my part. - Kris
Apr 09 2004
prev sibling next sibling parent C <dont respond.com> writes:
 Sigh. Double Sigh.  Any ideas? Suggestions? Resolutions? Should I just=

 give
 up?

Patience. All good things take time. You've made a good case and I thi= nk = Walter realizes something must be done. C On Tue, 6 Apr 2004 22:09:00 -0800, Kris = <someidiot earthlink.dot.dot.dot.net> wrote:
 I'm sure many of you are sick to death of hearing about Interface rela=

 flaws and bugs: personally, I'm thoroughly fed up of running into them=

 This
 one is another doozy ...

 OK; so we have a extensible Tokenizer subsystem. It scans input for
 delimited content and places the results in a Token. Here's a =

 stripped-down
 version of the participants:

 class Token
 {
     private char[] value;

     void setValue (char[] value)
     {
        this.value =3D value;
     }
 }

 class Tokenizer
 {
     abstract bool next (Token token);

     // other base-class stuff here
 }

 class LineTokenizer : Tokenizer
 {
     bool next (Token token)
     {
     // do some stuff

     // set Token content
     token.setValue (....);
     }
 }

 There are a variety of Tokenizer derivatives that handle different =

 scanning
 flavours. We can specialize with a SpaceTokenizer, CommaTokenizer,
 RegexTokenizer, and so on. They all operate upon the basic Token class=

 Now, we wish to introduce a *slightly* more sophisticated Token =

 derivative
 called CookieToken:

 class CookieToken : Token
 {
     private char[] name;

     void setName (char[] name)
     {
         this.name =3D name;
     }
 }

 ... and we want to pass it to a CookieTokenizer:

 class CookieTokenizer : Tokenizer
 {
     bool next (CookieToken token)
     {
     // do some stuff

     // set Token content
     token.setValue (....);
     token.setName (...);
     }
 }

 Note how the abstract method next() should accept a CookieToken rather=

 than
 the basic Token?

 So, the compiler says (and I quote)  "No wayyy pal. CookieTokenizer is=

 now
 one o' them abstract-classes cos' yer method signatures cannae be =

 matched".

 OK. Fair enough, Mr Compiler. This is where the power of Interfaces is=

 typically brought to bear: one would simply "virtualize" the basic Tok=

 class with an IToken interface.

 "All ABOARD!".   Here we go now ...

 // define interface
 interface IToken
 {
    void setValue (char[]);
 }

 // specify that our Token implements the IToken interface
 class Token : IToken
 {
    void setValue (char[]);
 }

 // update Tokenizer base-class with the Interface
 class Tokenizer
 {
     abstract bool next (IToken token);

     // other base-class stuff here
 }

 // update LineTokenizer with the Interface
 class LineTokenizer : Tokenizer
 {
     bool next (IToken token)
     {
     // do some stuff

     // set Token content
     token.setValue (....);
     }
 }

 So far so good.  Now we should be able to pass our CookieToken to the =

 next()
 method because it is an *instance* of the IToken Interface. This =

 concept  is
 a fundamental of contractual-specification support that an OO Interfac=

 exposes:

 class CookieTokenizer : Tokenizer
 {
     bool next (CookieToken token)
     {
     // do some stuff

     // set Token content
     token.setValue (....);
     token.setName (...);
     }
 }

 Hey Presto!

 Whoops! Compiler says "Oan yer bike pally! Ahh don't care a wee flying=

 *&%#
 if yer CookieToken is an IToken instance or no!"

 Well, what can one say to that?  Actually, I can think of a few choice=

 phrases ...

 This is Interfaces 101, people. It doesn't even pass the sniff test. O=

 might confidently state that the method-matching algorithm has =

 absolutely no
 concept of Interfaces.

 You might think one could use a base-class instead right? Well,
 unfortunately, that didn't work in the first instance (before the =

 Interface
 attempt). Apparently, D simply does not grok the concept of passing =

 derived
 objects as an argument via a base-class. Let alone Interfaces. Can any=

 say "polymorphic meltdown" ?

 Sigh. Double Sigh.  Any ideas? Suggestions? Resolutions? Should I just=

 give
 up?

 - Kris

-- = D Newsgroup.
Apr 07 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
Just to be sure, could you please post a complete example that illustrates
the problem, rather than me trying to piece one together? That way, it
avoids misunderstandings on my part.
Apr 07 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"Walter" <walter digitalmars.com> wrote in message:
 Just to be sure, could you please post a complete example that illustrates
 the problem, rather than me trying to piece one together? That way, it
 avoids misunderstandings on my part.

Yes, I will send you an example Walter. What I ask in return, and what I feel is *far* more valuable, is for you to please review the attached document and comment on the following suggested items: a) what you agree with as valuable, and what you think is worthless. Both specifically with respect to the D language. b) if there are features in there that are agreeable to you, then when (what version) you would expect them to be fully supported. That document effectively represents an Interface (contract) with respect to these issues <g>. If you're not prepared to come to the table and discuss, then there's not much else to talk about, is there? If you wish to continue receiving "support" from me, then you truly have to make certain commitments one way or another. I sincerely hope you find that agreeable. If, for instance, you don't agree with any of the points made in said document, then I'd simply be wasting my time (and those on this newsgroup) by extending this particular thread, and by sending you further examples. On the other hand, receiving widespread free "support", plus a usable code-base, from this NG is surely worth a few solid commitments? Respectfully, - Kris p.s. the attached is the version which differentiates between COM interface and OO Interface, and where the frustration-meter is toned down a little.
Apr 07 2004
parent "Phill" <phill pacific.net.au> writes:
Would it be possible to post the (simple) example? :o))

Phill.


"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c524gh$1nnm$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message:
 Just to be sure, could you please post a complete example that


 the problem, rather than me trying to piece one together? That way, it
 avoids misunderstandings on my part.

Yes, I will send you an example Walter. What I ask in return, and what I feel is *far* more valuable, is for you to please review the attached document and comment on the following suggested items: a) what you agree with as valuable, and what you think is worthless. Both specifically with respect to the D language. b) if there are features in there that are agreeable to you, then when

 version) you would expect them to be fully supported.

 That document effectively represents an Interface (contract) with respect

 these issues <g>. If you're not prepared to come to the table and discuss,
 then there's not much else to talk about, is there?

 If you wish to continue receiving "support" from me, then you truly have

 make certain commitments one way or another. I sincerely hope you find

 agreeable.

 If, for instance, you don't agree with any of the points made in said
 document, then I'd simply be wasting my time (and those on this newsgroup)
 by extending this particular thread, and by sending you further examples.

 the other hand, receiving widespread free "support", plus a usable
 code-base, from this NG is surely worth a few solid commitments?

 Respectfully,

 - Kris


 p.s. the attached is the version which differentiates between COM

 and OO Interface, and where the frustration-meter is toned down a little.

--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.648 / Virus Database: 415 - Release Date: 3/31/2004
Apr 07 2004