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

"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

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

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

"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

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

"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