"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c4ska9$2f70$1@digitaldaemon.com...
> Thank-you Walter. I truly appreciate your help on this.
>
> BTW, is this the expected long-term solution? If so (and I don't think it should be <g>) the compiler really needs to toss an error, rather than emitting grossly unjust access-violators ...

It's the long term solution <g>. The reason for the null result is to mimic the behavior of dynamic_cast in C++.

I think this idea of yours will work fine. A hidden method cannot be added, though, because then it would not work as a COM object.

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c4smb9$2imr$1@digitaldaemon.com...
> Please forgive my gratuitous overuse of this NG ...
>
> Thinking about this a little more Walter, if the base-interface were to implement just the upcast to a concrete Object, then dynamic-casting
should
> handle it from there. For example:
>
> interface IConduit
> {
>     Object  toObject();
> }
>
> class SocketConduit : IConduit
> {
>     Object  toObject() { return this; }
> }
>
> char[] getRemoteAddress(IConduit conduit)
> {
>     SocketConduit socket = cast(SocketConduit) conduit.toObject();
> }
>
> This, at least, is extensible. Though I'm torn as to whether it's the right-thing-to-do <g>
>
> Note:  one might be tempted to implement this instead as:
>
> interface IConduit
> {
>     Conduit  toConduit();
> }
>
> ...assuming there were a base-class implementation for IConduit.
>
> However, that doesn't lend itself toward a sense of 'pattern' (let alone
the
> potential "forward reference" issues that an Interfaces is handy for resolving).
>
> If, in fact, you were to decide the suggested approach is the long-term solution, then you might consider adding a hidden toObject() declaration
to
> each interface, and the corresponding "return this;" implementation to
each
> of the appropriate classes. If so, toObject() could thus become a property of any Interface. Not too sure about that attitude though.
>
>
>
>
>
> "Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c4skns$2fu9$1@digitaldaemon.com...
> > The solution provided works fine to skirt the issue at hand, but the
> > methodology requires that the base-class (or base-interface) is
> > pre-configured to know about *all possible derivations* (subclasses).
> That,
> > is simply unrealistic.
> >
>
>

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:c4snu4$2kv8$1@digitaldaemon.com...
> Walter wrote:
> > The problem here is that all an interface is, when implemented, is a
pointer
> > to a vtbl[]. There's no way the runtime can tell where it came from, so there is no way to upcast it.
>
> "No way", as in "impossible", or in "no way" as in "not for 1.0"? ;)
>
> Couldn't there be a virtual function "Object __getObject()" that is automatically generated for all classes? Then the cast operator could simply call this function when casting an interface to an object. Seems like the only way to have the cast operator behave consistently.

It could, but then it would be incompatible with COM programming.

> It could, but then it would be incompatible with COM programming.

Forgive my ignorance, but why would it be incompatible ?

C


On Mon, 5 Apr 2004 16:06:30 -0700, Walter <walter@digitalmars.com> wrote:

>
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message
> news:c4snu4$2kv8$1@digitaldaemon.com...
>> Walter wrote:
>> > The problem here is that all an interface is, when implemented, is a
> pointer
>> > to a vtbl[]. There's no way the runtime can tell where it came from, 
>> so
>> > there is no way to upcast it.
>>
>> "No way", as in "impossible", or in "no way" as in "not for 1.0"? ;)
>>
>> Couldn't there be a virtual function "Object __getObject()" that is
>> automatically generated for all classes? Then the cast operator could
>> simply call this function when casting an interface to an object. Seems
>> like the only way to have the cast operator behave consistently.
>
> It could, but then it would be incompatible with COM programming.
>
>



-- 
D Newsgroup.

C wrote:
>> It could, but then it would be incompatible with COM programming.
> 
> 
> Forgive my ignorance, but why would it be incompatible ?

I guess what Walter means is that then it would be very hard to cast a COM object into a D interface, since COM interfaces don't have a delete or toObject method by default.

But the thing is, I believe this kind of problem already exists and cannot be circumvented. COM objects cannot be collected by the garbage collector, since the COM rules state that a Release call is the only way a COM object can be deleted. So you cannot explicitly delete COM objects and you cannot leave them to be collected. You HAVE to do your own memory management, i.e. you cannot treat them like other D interfaces.

So, since COM and D interfaces are already incompatible I fail to see the reason why further incompatibilities should be a reason to restrict D.

What this all comes down to is that you ALREADY have to be aware that you deal with a COM interface instead of a D interface and treat it differently. So you can just as well remember that toObject or delete will return null / have no effect, whatever.

Hauke

"Walter" <walter@digitalmars.com> wrote in message news:c4sk0f$2eon$1@digitaldaemon.com...
> The problem here is that all an interface is, when implemented, is a
pointer
> to a vtbl[]. There's no way the runtime can tell where it came from, so there is no way to upcast it.

I don't know the internals all that well, but at runtime the object
implementing
the interface knows its class, right? Isn't that how dynamic casting works?
Is the problem that there exist "ClassInfo" but no "InterfaceInfo"?

-Ben

As Kris notes in a reply elsewhere, this is problematic because then the interface (and all classes which implement the interface) must know all derived classes.  How about this mechanism instead, which (if it works) could easily be implemented automatically by the compiler:

interface IConduit
{
	Object getObject();
}
class SocketConduit : IConduit
{
	Object getObject() { return this; }
}

char[] getRemoteAddress(IConduit conduit)
{
	SocketConduit socket = cast(SocketConduit)conduit.getObject();
}

That is, every interface includes a function which will return an Object reference...then normal D casting mechanisms can upcast the Object to whatever class you think it is.

IMHO, this should be the automatic behavior when you try to cast an interface to a class...the compiler should do this for you.

Thoughts?

Walter wrote:
> The problem here is that all an interface is, when implemented, is a pointer
> to a vtbl[]. There's no way the runtime can tell where it came from, so
> there is no way to upcast it.
> 
> The way to deal with this is to add a member function to the interface that
> is equivalent to the 'ClassFactory' function in COM programming. Then, in
> the implementation of that function, which does know the object type
> enclosing the interface, the cast can be done.
> 
> interface IConduit
> {
>     SocketConduit isSocketConduit();
> }
> 
> class SocketConduit : IConduit
> {
>     SocketConduit isSocketConduit() { return this; }
> }
> 
> char[] getRemoteAddress(IConduit conduit)
> {
>     SocketConduit socket = conduit.isSocketConduit();
> }
> 
> 
> "Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message
> news:c4qi35$24f8$1@digitaldaemon.com...
> 
>>I have a concrete-class that implements a generic interface. On occasion,
>>said interface needs to be upcast to the concrete-class to access
>>specialized functionality. Check out the cast(SocketConduit) code below
> 
> ...
> 
>>it explicitly sets the lValue to zero.  Good Grief ...
>>
>>112:          char[] getRemoteAddress (IConduit conduit)
>>00403290   enter       0Ch,0
>>00403294   mov         dword ptr [ebp-0Ch],eax
>>113:          {
>>114:                  SocketConduit socket = cast(SocketConduit) conduit;
>>00403297   xor         eax,eax
>>00403299   mov         dword ptr [socket],eax