The delete operator cannot successfully be applied to an Interface. I traced it through the assembly, and it barfs an access-violation deep within some compiler support code.

void cross (IConduit conduit)
{
       <snip>
       try {
            <snip>
            } finally {
                        conduit.close();
                        delete conduit;
                        }
}

Is it just me, or does anyone else feel that interfaces are seriously broken?

- Kris

I haven't used them that extensively, but based on these reports, yea they need work :/.  I dont think you should have to change your design ( which looks quite nice! ) to accomodate broken language features.

On a side note ( hope this doesnt sound to fruity ) , your posts are always really well written, makes it a joy to read :D.  English major ?

C

On Sun, 4 Apr 2004 19:14:05 -0800, Kris <someidiot@earthlink.dot.dot.dot.net> wrote:

> The delete operator cannot successfully be applied to an Interface. I traced
> it through the assembly, and it barfs an access-violation deep within some
> compiler support code.
>
> void cross (IConduit conduit)
> {
>        <snip>
>        try {
>             <snip>
>             } finally {
>                         conduit.close();
>                         delete conduit;
>                         }
> }
>
> Is it just me, or does anyone else feel that interfaces are seriously
> broken?
>
> - Kris
>
>



-- 
D Newsgroup.

Uhh, Scottish education; but I failed all my English exams in school. Every single one of 'em. Miserably so <g>

>C wrote:
>On a side note ( hope this doesnt sound to fruity ) , your posts are
>always really well written, makes it a joy to read :D.  English major ?

Kris wrote:

> Is it just me, or does anyone else feel that interfaces are seriously
> broken?

Hmm mm. (Or 'I agree')

Good night, and have a good Easter.

Cheers,
Sigbjørn Lund Olsen

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c4qifs$253d$1@digitaldaemon.com...
> The delete operator cannot successfully be applied to an Interface.

That's because an interface is not a new'd object, and so delete cannot be applied to it.

> I traced
> it through the assembly, and it barfs an access-violation deep within some
> compiler support code.
>
> void cross (IConduit conduit)
> {
>        <snip>
>        try {
>             <snip>
>             } finally {
>                         conduit.close();
>                         delete conduit;
>                         }
> }
>
> Is it just me, or does anyone else feel that interfaces are seriously broken?

I think it's a misunderstanding of what interfaces really are. Interfaces are not objects that can be new'd and delete'd, though perhaps the compiler should issue an error if one tries to delete an interface.

"Walter" <walter@digitalmars.com> wrote in message news:c4spaf$2n6e$3@digitaldaemon.com...
> I think it's a misunderstanding of what interfaces really are. Interfaces are not objects that can be new'd and delete'd, though perhaps the
compiler
> should issue an error if one tries to delete an interface.
>
>

As you say, I think there perhaps is a misunderstanding.

How does one expose public modules within any truly decoupled large-scale-development? Through an Interface. That's primarily what they are intended for. Anyone familiar with the Factory Pattern will attest to this. If I provide a factory method to create and return a concrete instance of the exposed Interface, how does the 'user' then subsequently dispose of it? Through a factory provided 'dispose' method? If so, then it is specialization at the language level, and flies in the face of symmetry and ease-of-use. Without wishing to be rhetorical, how did you intend such usage to transpire?

Naturally, one cannot "new" an Interface, as you say.

My, admittedly testy, comment about Interfaces being "thoroughly broken" was somewhat unwarranted ... and I beg your pardon Walter. However, it came about as a result of the many problems surrounding said implementation, whereas the rest of the language is comparatively stable. I have personally documented four or five different scenarios of access-violations related to seemingly innocuous applications of Interfaces (part to this NG, part directly to you), whereas I've run into zero with any other language feature. I, for one, believe that any access-violation via what appears to be normal usage of a language feature makes it unfit for general consumption.

I say this not as a kick-the-tires user, but as one who currently has ~600K of D source written for a "real-world" language test (IO package, HTTP server, and Servlet Container). As a result, I will personally vouch that D is every bit as good as advertised with respect to developing robust working code (as good as, and notionally better than, Java in that respect). Yet there are still some glaring rough edges (such as this topic) that need serious attention.

As a side note -- suggestions made in the related thread (to resolve the upcasting of an Interface into a concrete class) would also resolve this issue: the interface would first be converted to its concrete-object via method toObject(), then deleted per usual. In fact, that's exactly what I'm doing to work around this 'flaw'.

Regards,

- Kris

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c4svch$30v7$1@digitaldaemon.com...
> How does one expose public modules within any truly decoupled large-scale-development? Through an Interface. That's primarily what they are intended for. Anyone familiar with the Factory Pattern will attest to this. If I provide a factory method to create and return a concrete
instance
> of the exposed Interface, how does the 'user' then subsequently dispose of it? Through a factory provided 'dispose' method? If so, then it is specialization at the language level, and flies in the face of symmetry
and
> ease-of-use. Without wishing to be rhetorical, how did you intend such
usage
> to transpire?

The way COM objects deal with this issue is there is, indeed, a method (Release()) in the interface which the interface implementor must implement. Other than that, the garbage collector will handle most cleanup needs.

> Naturally, one cannot "new" an Interface, as you say.

Yes, and so I would argue it is surprising and asymmetric if one could 'delete' one.

> My, admittedly testy, comment about Interfaces being "thoroughly broken"
was
> somewhat unwarranted ... and I beg your pardon Walter. However, it came about as a result of the many problems surrounding said implementation, whereas the rest of the language is comparatively stable. I have
personally
> documented four or five different scenarios of access-violations related
to
> seemingly innocuous applications of Interfaces (part to this NG, part directly to you), whereas I've run into zero with any other language feature. I, for one, believe that any access-violation via what appears to be normal usage of a language feature makes it unfit for general consumption.

I think the solution here is to issue an error message on attempting to 'delete' an interface.

> I say this not as a kick-the-tires user, but as one who currently has
~600K
> of D source written for a "real-world" language test (IO package, HTTP server, and Servlet Container). As a result, I will personally vouch that
D
> is every bit as good as advertised with respect to developing robust
working
> code (as good as, and notionally better than, Java in that respect). Yet
> there are still some glaring rough edges (such as this topic) that need
> serious attention.

That's really great to hear!

> As a side note -- suggestions made in the related thread (to resolve the upcasting of an Interface into a concrete class) would also resolve this issue: the interface would first be converted to its concrete-object via method toObject(), then deleted per usual. In fact, that's exactly what
I'm
> doing to work around this 'flaw'.

I think you're on the right track with that.

"Walter" <walter@digitalmars.com> wrote in message news:c4t2e4$3kh$1@digitaldaemon.com...
>
> The way COM objects deal with this issue is there is, indeed, a method
> (Release()) in the interface which the interface implementor must
implement.
> Other than that, the garbage collector will handle most cleanup needs.

I can't imagine that you believe COM is an ideal model. You have the opportunity to bring this kind of management issue within the fold of the language proper, in the same way that Java (and others) do, yet you wish us to emulate what Microsoft hacked together 15 years ago?

>
> I think the solution here is to issue an error message on attempting to 'delete' an interface.
>
If that's the case, then the compiler should also issue an error when upcasting an interface to an implementing object. You previously indicated that particular access-violation is in accordance with the C++ dynmic_cast implementation (and hence acceptable). Surely it would be easier for the compiler to issue an error than for a developer to track down a somewhat obscure, and blatently deliberate, means of debilitating the runtime?

> > I say this not as a kick-the-tires user, but as one who currently has
> ~600K
> > of D source written for a "real-world" language test (IO package, HTTP server, and Servlet Container). As a result, I will personally vouch
that
> D
> > is every bit as good as advertised with respect to developing robust
> working
> > code (as good as, and notionally better than, Java in that respect). Yet
> > there are still some glaring rough edges (such as this topic) that need
> > serious attention.
>
> That's really great to hear!

I'm glad it appears to make you happy, but the take-home point is that Interfaces are a seriously weak spot in the D arsenel, and needs much attention.

Keep in mind that there are two distinct camps regarding the approach to a "new" language:

1) the enthusiast crowd, such as those present here, who like to try something new and are willing to put up with what they might feel are some 'oddities'. This includes those who feel they have an opportunity to shape the language in some form.

2) the commercial sector, who will go out of their way to find reason not to change the status-quo. I've personally performed this type of evaluation for companies in the past (vis-a-vis Java), and my experience tells me that *any* arguable issue becomes the prime reason for non-adoption.

I say this because, IMHO, the current D support for Interfaces will give the commercial folks plenty reason to disparage the language, and buttonhole it as just another pet-project. That would be a real shame, not just because the rest of the language appears robust and well thought-out.

> In fact, that's exactly what I'm doing to work around this 'flaw'.
>
> I think you're on the right track with that.

I'm afraid that is not an answer that will encourage wider adoption of D. What you're advocating here, Walter, is that we resort to decorating our implementations in some arcane manner so as to sidestep fundamental language design issues. This is akin to, and actually worse than, your "beloved" Hungarian notation -- do you wish people to "just say no" to D?

Regards,

- Kris

I understand your points, but there are some design contraints that D follows, and some compromises. For example, it is necessary to support Microsoft's COM conventions, or D will be non-viable for doing system work on Win32 systems. Much of the Win32 API is only available via COM interfaces. The format of a COM object is what it is, and nobody can change it now.

Java doesn't do any better than D with interfaces, after all, Java cannot delete an interface (or anything else, for that matter) either. Java relies completely on the garbage collector to recover memory.

For a cast that won't work, the options are:

1) compile time error - but these are not always detectable at compile time
2) return null
3) throw an exception at runtime

Java does (1) whenever it can. When it cannot, it winds up requiring two steps in the code, first test with instanceof, then cast. (If the cast is done first, and the cast is invalid, an exception is thrown.) I coded in Java for a while, and found the two steps to be simply redundant. D combines them into one operation, which is smaller and faster. Instead of a true/false from instance of, you get null/reference from the cast, which can be used directly.

Java:
    if (a instanceof b)
    {    p = (b)a;
        ...
    }

D:
    p = cast(b) a;
    if (p)
    {
        ...
    }

The reason that D does not do (1) is to better support generic template programming, which needs to be able to test properties of types without causing compile errors. Another reason is, as I mentioned previously, conceptual compatibility with C++'s dynamic_cast.

I don't know the details of your design, but perhaps a D abstract class might be a better fit. Those can be delete'd.

-Walter

Thanks for your thoughtful response Walter; I will try to respond in kind.

You do make some valid points, and I'm somewhat loath to dispute them further. But <g>, I will say two things:

1) "Java doesn't do any better than D with interfaces": On the contrary, Interfaces are true first-class citizens in Java. For example, one can happily cast an interface to its implementing class (and at any reasonable point of inheritance). One can also happily test whether one interface is also of another kind.

2) "p = cast(b) a;":  This may be smaller and faster, but I'd be happy if it just worked with interfaces <g>. Remember, I have a further bug-report (sent to you early last week) where there's an access-violation whilst attempting to see if one interface is a derivative of another. Surely (please!) you can agree the latter is a reasonable thing to attempt? People, and Companies, really do use interfaces as a contractual replacement for unavailable, pluggable, or hidden class implementations. And you typically cannot agreeably enforce the use of an abstract-base-class because of the single-root hierarchy.

Finally, I sincerely hope you don't take personal affront to such exchanges. After all, the overriding intention is to make D a more robust and usable development choice.

- Kris


"Walter" <walter@digitalmars.com> wrote in message news:c4tqaq$17ov$1@digitaldaemon.com...
> I understand your points, but there are some design contraints that D follows, and some compromises. For example, it is necessary to support Microsoft's COM conventions, or D will be non-viable for doing system work on Win32 systems. Much of the Win32 API is only available via COM interfaces. The format of a COM object is what it is, and nobody can
change
> it now.
>
> Java doesn't do any better than D with interfaces, after all, Java cannot delete an interface (or anything else, for that matter) either. Java
relies
> completely on the garbage collector to recover memory.
>
> For a cast that won't work, the options are:
>
> 1) compile time error - but these are not always detectable at compile
time
> 2) return null
> 3) throw an exception at runtime
>
> Java does (1) whenever it can. When it cannot, it winds up requiring two steps in the code, first test with instanceof, then cast. (If the cast is done first, and the cast is invalid, an exception is thrown.) I coded in Java for a while, and found the two steps to be simply redundant. D
combines
> them into one operation, which is smaller and faster. Instead of a true/false from instance of, you get null/reference from the cast, which
can
> be used directly.
>
> Java:
>     if (a instanceof b)
>     {    p = (b)a;
>         ...
>     }
>
> D:
>     p = cast(b) a;
>     if (p)
>     {
>         ...
>     }
>
> The reason that D does not do (1) is to better support generic template programming, which needs to be able to test properties of types without causing compile errors. Another reason is, as I mentioned previously, conceptual compatibility with C++'s dynamic_cast.
>
> I don't know the details of your design, but perhaps a D abstract class might be a better fit. Those can be delete'd.
>
> -Walter
>
>