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


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


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


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


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




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.


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




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




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








hod

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




 implement.

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








ds.


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






ts =


 a


 COM

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






TTP

 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.






-- =

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


it.

 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




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.


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