• "Kris" <someidiot earthlink.dot.dot.dot.net> Apr 06 2004
• "Ivan Senji" <ivan.senji public.srce.hr> Apr 07 2004
• "Kris" <someidiot earthlink.dot.dot.dot.net> Apr 07 2004
• "Ben Hinkle" <bhinkle4 juno.com> Apr 07 2004
• "Kris" <someidiot earthlink.dot.dot.dot.net> Apr 07 2004
• Ant <Ant_member pathlink.com> Apr 07 2004
• "Kris" <someidiot earthlink.dot.dot.dot.net> Apr 07 2004
• C <dont respond.com> Apr 07 2004
• "Phill" <phill pacific.net.au> Apr 08 2004
• John Reimer <jjreimer telus.net> Apr 08 2004
• "Ben Hinkle" <bhinkle4 juno.com> Apr 07 2004
• John Reimer <jjreimer telus.net> Apr 07 2004
• "Kris" <someidiot earthlink.dot.dot.dot.net> Apr 07 2004
• John Reimer <jjreimer telus.net> Apr 07 2004
• "Kris" <someidiot earthlink.dot.dot.dot.net> Apr 07 2004
• Russ Lewis <spamhole-2001-07-16 deming-os.org> Apr 08 2004
• "Kris" <someidiot earthlink.dot.dot.dot.net> Apr 09 2004
• C <dont respond.com> Apr 07 2004
• "Walter" <walter digitalmars.com> Apr 07 2004
• "Kris" <someidiot earthlink.dot.dot.dot.net> Apr 07 2004
• "Phill" <phill pacific.net.au> Apr 07 2004

"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

"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

"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

"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

"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

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

"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

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.

"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

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

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

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

"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

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.

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

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;

"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

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.

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

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

"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