www.digitalmars.com         C & C++   DMDScript  

D - [BUG] delete on an interface: access violation

reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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
Apr 04 2004
next sibling parent reply C <dont respond.com> writes:
I haven't used them that extensively, but based on these reports, yea th=
ey =

need work :/.  I dont think you should have to change your design ( whic=
h =

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.
Apr 04 2004
parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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 ?

Apr 04 2004
prev sibling next sibling parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
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
Apr 05 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Apr 05 2004
next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"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

 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
Apr 05 2004
parent reply "Walter" <walter digitalmars.com> writes:
"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

 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

 ease-of-use. Without wishing to be rhetorical, how did you intend such

 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"

 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

 documented four or five different scenarios of access-violations related

 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

 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

 is every bit as good as advertised with respect to developing robust

 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

 doing to work around this 'flaw'.

I think you're on the right track with that.
Apr 05 2004
next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"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

 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.

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

 of D source written for a "real-world" language test (IO package, HTTP
 server, and Servlet Container). As a result, I will personally vouch


 D
 is every bit as good as advertised with respect to developing robust

 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
Apr 05 2004
parent reply "Walter" <walter digitalmars.com> writes:
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
Apr 05 2004
next sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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

 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

 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

 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

 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

 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

Apr 06 2004
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Walter schrieb:
 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.

Basically, all that is requiered are a few methods in a basic interface? Then you can have such "magic" interface to hold them, and if an interface inherits from such a "magic" interface it allows to implement the operators in question in terms of these methods. This is optional and thus doesn't break the COM layout for the case an Interface is intended to really be COM. -eye
Apr 06 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:c4uopd$2k5f$1 digitaldaemon.com...
 Walter schrieb:
 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


 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


 it now.

Basically, all that is requiered are a few methods in a basic interface? Then you can have such "magic" interface to hold them, and if an interface inherits from such a "magic" interface it allows to implement the operators in question in terms of these methods. This is optional and thus doesn't break the COM layout for the case an Interface is intended to really be COM.

Putting magic methods in the basic interface adds slots in the vtbl[], and so makes it incompatible with other COM objects.
Apr 06 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Walter schrieb:

Basically, all that is requiered are a few methods in a basic interface?
Then you can have such "magic" interface to hold them, and if an
interface inherits from such a "magic" interface it allows to implement
the operators in question in terms of these methods. This is optional
and thus doesn't break the COM layout for the case an Interface is
intended to really be COM.

Putting magic methods in the basic interface adds slots in the vtbl[], and so makes it incompatible with other COM objects.

Yes, it's only for the cases where interfaces are to represent D objects and not COM objects. It doesn't fit with existing COM objects, but it may still meke sense if COM objects are made available from D. That's why this interface should not be basic to all automatically. Or is there anything else i'm missing? Are there any arguments why this addition may be redundant? -eye
Apr 06 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:c4v438$3f1$1 digitaldaemon.com...
 Yes, it's only for the cases where interfaces are to represent D objects
 and not COM objects. It doesn't fit with existing COM objects, but it
 may still meke sense if COM objects are made available from D. That's
 why this interface should not be basic to all automatically. Or is there
 anything else i'm missing?

 Are there any arguments why this addition may be redundant?

The COM objects have to work both ways - D must be able to access COM objects created by other languages that know nothing of D, and vice versa.
Apr 06 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
Walter schrieb:
 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:c4v438$3f1$1 digitaldaemon.com...
 
Yes, it's only for the cases where interfaces are to represent D objects
and not COM objects. It doesn't fit with existing COM objects, but it
may still meke sense if COM objects are made available from D. That's
why this interface should not be basic to all automatically. Or is there
anything else i'm missing?

Are there any arguments why this addition may be redundant?

The COM objects have to work both ways - D must be able to access COM objects created by other languages that know nothing of D, and vice versa.

OK, but not every interface should be intended to be a COM object, should it? Let me repost myself from another thread: --- 8< --- Another idea which does not requiere to change syntax: COM interface is built upon a "pure interface" by library means, just as XPCOM interface, and other interfaces which conflict with "D object interface". "D object interface", ie an interface supporting backcasting to D object, can be built from a pure interface by compiler means. I propose that whenever an interface ihnerits from "ObjectInterface", which may be a half-bogus interface reserving VTable space for requiered methods, these methods would be implemented for each class descendant of it automatically. A syntax may always be bound for all interfaces to ObjectInterface method calls (ie assume they are there), which would allow to implement similar behaviours in library, and would correctly give errors when you try such a syntax (ie backcasting) on an interface which does not support it. --- >8 --- There really should be a more or less standardized way to create and work with object interfaces. I understand that the issue is not immediate and one could currently do such a method on his own, especially with a mix-in technique. -eye
Apr 07 2004
prev sibling next sibling parent Vathix <vathix dprogramming.com> writes:
Walter wrote:
 "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.

You can't new an abstract class object but you can delete one? I'd say it would be more of a convenience if you could delete the interface reference (if you could cast back to the class object). Would it be possible to implicitly add a toObject() to interfaces, but on the end of the function table rather than the beginning, to allow the cast? Isn't that essentially what we'd be doing manually? Sorry if I'm way off; I don't completely understand. -- Christopher E. Miller
Apr 06 2004
prev sibling parent reply Carlos Santander B. <Carlos_member pathlink.com> writes:
In article <c4t2e4$3kh$1 digitaldaemon.com>, Walter says...
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 don't know about COM, but maybe the thing is that not everyone wants a COM interface as a D interface. I mean, taking Kris' code, what does a HTTP server has to do with COM? So probably it'd be reasonable to be able to separate D and COM interfaces. ------------------- Carlos Santander B.
Apr 06 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Carlos Santander B." <Carlos_member pathlink.com> wrote in message
news:c4uhkn$29lv$1 digitaldaemon.com...
 In article <c4t2e4$3kh$1 digitaldaemon.com>, Walter says...
The way COM objects deal with this issue is there is, indeed, a method
(Release()) in the interface which the interface implementor must


Other than that, the garbage collector will handle most cleanup needs.

I don't know about COM, but maybe the thing is that not everyone wants a

 interface as a D interface. I mean, taking Kris' code, what does a HTTP

 has to do with COM? So probably it'd be reasonable to be able to separate

 COM interfaces.

The thing about COM is, much Win32 system programming revolves around using COM objects. Changes that make D interfaces incompatible with COM are going to cripple D's ability to write real system code under Win32.
Apr 06 2004
next sibling parent reply larry cowan <larry_member pathlink.com> writes:
Seems like a real need is involved on both sides.  What about 2 categories of
interface - an interface and an intercom?

In article <c4v0bh$2v80$1 digitaldaemon.com>, Walter says...
"Carlos Santander B." <Carlos_member pathlink.com> wrote in message
news:c4uhkn$29lv$1 digitaldaemon.com...
 In article <c4t2e4$3kh$1 digitaldaemon.com>, Walter says...
The way COM objects deal with this issue is there is, indeed, a method
(Release()) in the interface which the interface implementor must


Other than that, the garbage collector will handle most cleanup needs.

I don't know about COM, but maybe the thing is that not everyone wants a

 interface as a D interface. I mean, taking Kris' code, what does a HTTP

 has to do with COM? So probably it'd be reasonable to be able to separate

 COM interfaces.

The thing about COM is, much Win32 system programming revolves around using COM objects. Changes that make D interfaces incompatible with COM are going to cripple D's ability to write real system code under Win32.

Apr 06 2004
next sibling parent C <dont respond.com> writes:
Yes this gets my vote.  I see that interface is important for COM and CO=
M =

users, but I dont think that most people using interfaces are programmin=
g =

for COM ( maybe im wrong ).  It seems we're appealing to the minority wi=
th =

keeping interfaces strictly for COM, and missing out on alot of good =

programming design possibilities.

How hard would it be to implement the hidden toOject method ?

C


On Tue, 6 Apr 2004 19:39:38 +0000 (UTC), larry cowan =

<larry_member pathlink.com> wrote:

 Seems like a real need is involved on both sides.  What about 2 =

 categories of
 interface - an interface and an intercom?

 In article <c4v0bh$2v80$1 digitaldaemon.com>, Walter says...
 "Carlos Santander B." <Carlos_member pathlink.com> wrote in message
 news:c4uhkn$29lv$1 digitaldaemon.com...
 In article <c4t2e4$3kh$1 digitaldaemon.com>, Walter says...
The way COM objects deal with this issue is there is, indeed, a met=




(Release()) in the interface which the interface implementor must


Other than that, the garbage collector will handle most cleanup nee=





I don't know about COM, but maybe the thing is that not everyone wan=



 a

 interface as a D interface. I mean, taking Kris' code, what does a H=



 server
 has to do with COM? So probably it'd be reasonable to be able to =



 separate

 COM interfaces.

The thing about COM is, much Win32 system programming revolves around=


 using
 COM objects. Changes that make D interfaces incompatible with COM are=


 going
 to cripple D's ability to write real system code under Win32.


-- = D Newsgroup.
Apr 06 2004
prev sibling parent Stephan Wienczny <wienczny web.de> writes:
One question: "Will this solution work with Corba or any other 
middleware,too?"

If it does it gets my vote.


larry cowan wrote:

 Seems like a real need is involved on both sides.  What about 2 categories of
 interface - an interface and an intercom?
 
 In article <c4v0bh$2v80$1 digitaldaemon.com>, Walter says...
 
"Carlos Santander B." <Carlos_member pathlink.com> wrote in message
news:c4uhkn$29lv$1 digitaldaemon.com...

In article <c4t2e4$3kh$1 digitaldaemon.com>, Walter says...

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 don't know about COM, but maybe the thing is that not everyone wants a

COM
interface as a D interface. I mean, taking Kris' code, what does a HTTP

server
has to do with COM? So probably it'd be reasonable to be able to separate

D and
COM interfaces.

The thing about COM is, much Win32 system programming revolves around using COM objects. Changes that make D interfaces incompatible with COM are going to cripple D's ability to write real system code under Win32.


Apr 06 2004
prev sibling next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
 The thing about COM is, much Win32 system programming revolves around using
 COM objects. Changes that make D interfaces incompatible with COM are going
 to cripple D's ability to write real system code under Win32.

So we can either have what I'd call "half-assed" (no insult intended) interface support (compared with other languages such as Java) or they wouldn't be COM compatible. It just seems wrong to design such a basic language feature around one OS and an already obsolete programming technique (MS already switched to .NET for their new stuff). Why not have both? What about a modifier, like "extern(windows) interface IUnknown"? Such interfaces cannot be casted to their object and they cannot be deleted. It seems to be very much like function calling conventions. For example, a stdcall method also cannot have a variable number of parameters, i.e. this language feature is unsupported for the calling convention. Same with interfaces: the casting-to-object and deleting features are unsupported for "extern(windows)" interfaces. Hauke
Apr 06 2004
parent reply Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
Hauke Duden <H.NS.Duden gmx.net> wrote:

 Why not have both? What about a modifier, like "extern(windows) 
 interface IUnknown"? Such interfaces cannot be casted to their object 
 and they cannot be deleted. It seems to be very much like function 
 calling conventions. For example, a stdcall method also cannot have a 
 variable number of parameters, i.e. this language feature is
 unsupported for the calling convention. Same with interfaces: the
 casting-to-object and deleting features are unsupported for
 "extern(windows)" interfaces. 

This line of thinking gets my vote. COM, although widely used in the Microsoft world, is a special case, and is not a good basis for modern OOP design. I think we all agree on these points, and that D should support it. The only question is _how_. I especially like the idea of some new attribute or keyword to denote COM compatibility. I don't think anyone would complain about that, because it is not forced on anyone. People who are not using COM, on Windows or any other platform, should not be stuck with COM's design. People who *are* using COM are already used to having many kludges in their code, so it shouldn't bother them to continue that tradition when programming in D. -- dave
Apr 06 2004
parent reply "Phill" <phill pacific.net.au> writes:
"Dave Sieber" <dsieber spamnot.sbcglobal.net> wrote in message
news:Xns94C3A55C52ACdsiebersbc 63.105.9.61...
 Hauke Duden <H.NS.Duden gmx.net> wrote:

 Why not have both? What about a modifier, like "extern(windows)
 interface IUnknown"? Such interfaces cannot be casted to their object
 and they cannot be deleted. It seems to be very much like function
 calling conventions. For example, a stdcall method also cannot have a
 variable number of parameters, i.e. this language feature is
 unsupported for the calling convention. Same with interfaces: the
 casting-to-object and deleting features are unsupported for
 "extern(windows)" interfaces.

This line of thinking gets my vote. COM, although widely used in the Microsoft world, is a special case, and is not a good basis for modern OOP design. I think we all agree on these points, and that D should support

 The only question is _how_.

 I especially like the idea of some new attribute or keyword to denote COM
 compatibility.

That idea sounds great to me. This Thread is very depressing(like a step back for D). But as everyone knows, somtimes you have to take a step back to take two steps forward. Its a real pity this problem wasnt brought up(or noticed) earlier. Phill. --- 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
parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"Phill" <phill pacific.net.au> wrote in message
news:c50ihe$2bvh$1 digitaldaemon.com...
 This Thread is very depressing(like a step back
 for D).
 But as everyone knows, somtimes you have to
 take a step back to take two steps forward.

 Its a real pity this problem wasnt brought up(or
 noticed) earlier.

It is depressing, especially since Interface problems have been brought up before in one form or another. Still ... better for it to be roughed-up a little in the relative safety of this lagoon, than be torn to pieces by the sharks beyond the reef. Having said that, I think it would be less depressing for all if there were some true positive commitment on resolving the Interface issue. How about it Walter? - Kris
Apr 07 2004
prev sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:c4v0bh$2v80$1 digitaldaemon.com...
 The thing about COM is, much Win32 system programming revolves around


 COM objects. Changes that make D interfaces incompatible with COM are

 to cripple D's ability to write real system code under Win32.

I really don't think anyone is contesting that D should abandon COM support Walter. You've already come up with some rather elegant solutions for tricky problems, and it's this that makes D so attractive in specific areas. Iterators are a good example of your ability to think outside-the-box. What's needed is an elegant solution that provides not only backward COM support, but the more forward-thinking and highly desirable/prized OO Interface support. I have no doubt in my mind as to your ability to succeed in this. - Kris
Apr 06 2004
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:
 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.

I understand what you are saying at a technical level, but IMHO this does mean that the DESIGN OF interfaces are broken at the language level. I have argued a number of times here on this NG that interfaces are a good substitute for multiple inheritance. They allow you to take a reference to a sort-of "2nd base class" of a class you've defined. However, if that is true, then we need to be able to cast & to delete these references...otherwise, they don't really give us the amount of programatic power that real multiple inheritance would. In this case, I would opine that the 'delete' operator should take, as an argument, either a pointer or an Object reference. When you pass it an interface, the compiler should make an implicit cast Interface->Object using the automatically generated getObject() function I proposed in my other post. Thoughts?
Apr 06 2004