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

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?

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.

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

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

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

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

Yes this gets my vote.  I see that interface is important for COM and COM users, but I dont think that most people using interfaces are programming for COM ( maybe im wrong ).  It seems we're appealing to the minority with 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 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.
>>
>>
>
>



-- 
D Newsgroup.

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

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