Matthew wrote:

>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
>news:bur8ut$6gj$2@digitaldaemon.com...
>  
>
>>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>>news:bur6fm$283$1@digitaldaemon.com...
>>    
>>
>>>John Reimer wrote:
>>>
>>>      
>>>
>>>>In the D Language Manual Overview, it states:
>>>>
>>>>Features to Keep From C/C++
>>>>
>>>>"Runtime Type Identification. This is partially implemented in C++; in
>>>>        
>>>>
>D
>  
>
>>>>it is taken to its next logical step. Fully supporting it enables
>>>>        
>>>>
>better
>  
>
>>>>garbage collection, better debugger support, more automated
>>>>        
>>>>
>persistence,
>  
>
>>>>etc."
>>>>
>>>>How is it supported in D? What features enable it? Is this visible to
>>>>        
>>>>
>the
>  
>
>>>>programmer?  I haven't been able to see where the D language enables to
>>>>identify the type or class at runtime.
>>>>
>>>>
>>>>        
>>>>
>>>You can use *ClassInfo. *
>>>
>>>ie
>>>object.classinfo.name
>>>      
>>>
>>NO!
>>
>>Sorry for shouting, but there must be one accepted way of performing
>>downcasting, so that all programmers - especially newcomers - have a
>>    
>>
>single
>  
>
>>token that they must be on guard for.
>>
>>Otherwise, it's going to be a disgusting sorry mess, reminiscent of Java
>>    
>>
>or
>  
>
>>RTTI-mad C++ (and yes, I _have_ perpetrated my fair share of evils in
>>    
>>
>this,
>  
>
>>so have much blame on my own shoulders)
>>    
>>
>
>Hmm. Maybe that'll teach me not to be working in the small hours. I thought
>you were recommending this as a mechanism for downcasting. Re-reading this
>makes me wonder whether that is the case. If it is, the shout stays. If not,
>then I shall flagellate myself soundly on your behalf.
>
>:)
>
>Dr Proctor
>
>
>  
>
I was referring to his RTTI question ie getting the name of a class.

-- 
-Anderson: http://badmama.com.au/~anderson/

> To set people straight here.  This code was a modified example of what the Java SWT GUI class does.  I posted it here so I could get help on how to work the code in D (trying to port this).  The real code tests using instanceof and then promptly downcasts if the object is found valid. Bad design? I really don't know if it is. But 99% chance that it is. :-)
>
> So it wasn't just me! I was just the unfortunate simpleton to choke on this candy.

I wasn't singling you out, or wasn't meaning to anyway. I'm a little bit nuts atm, as it's 2am, and I've been working since 7am yesterday. However, I've just finished the last chapter of the book. Hurrah!!

(Now for all the boring editing stuff. Boo!)

> Later,
>
> John

> 
> I wasn't singling you out, or wasn't meaning to anyway. I'm a little bit nuts atm, as it's 2am, and I've been working since 7am yesterday. However, I've just finished the last chapter of the book. Hurrah!!
> 
> (Now for all the boring editing stuff. Boo!)

Ah, no problem.  Just trying to pass the blame :).  Congrats on the book!

- John

PS.  Remember you promised that all 18 of us (can't remember the number) could order it when it was done? ;-)  We'll make you rich yet! Hope it has something on downcasting for me.

> You can use *ClassInfo. *
> 
> ie
> object.classinfo.name
> 
> Check out:
> http://www.digitalmars.com/d/phobos.html#object
> 
> The only real documentation is in object.d.

Thanks once again. I tested the feature thoroughly and found it quite useful.  It worked much better than I expected.  It was exactly what I was looking for.

Later,

John

I dont see how testing to see if an Object
is an instanceof another Object BEFORE
downcasting can be bad in anyway, in fact, its
a bit like wearing a condom isnt it?

Phill.


"John Reimer" <jjreimer@telus.net> wrote in message news:pan.2004.01.23.14.14.58.592271@telus.net...
> To set people straight here.  This code was a modified example of what the Java SWT GUI class does.  I posted it here so I could get help on how to work the code in D (trying to port this).  The real code tests using instanceof and then promptly downcasts if the object is found valid. Bad design? I really don't know if it is. But 99% chance that it is. :-)
>
> So it wasn't just me! I was just the unfortunate simpleton to choke on this candy.
>
> Later,
>
> John

> I dont see how testing to see if an Object
> is an instanceof another Object BEFORE
> downcasting can be bad in anyway, in fact, its
> a bit like wearing a condom isnt it?

There are two separate issues that you're commenting on here. If you're going to downcast, then it's certainly better to avoid doing a check before and to have the success of the cast provide the information you require.

This is, however, a somewhat muddied issue. In C++, dynamic_cast<> on pointers returns NULL, whereas on references it (by necessity) throws std::bad_cast. If D is to have overt support for downcasting, then there would be equivocation on whether it should return NULL or should throw a BadCastException, or whatever. If someone can suggest a clear and unambiguous syntax, it might be best to have both options supported at the language level.

On a broader perspective, the notion of whether to check the putative success of a downcast before you make it is a moot point, since it is the badness of the downcast that is preeminent. In general it is fair to say that, except for a worthwhile subset of operations (such as GUI IDDEs, code analysers, code generators, etc.), downcasting indicates bad design. Unfortunately, this does not always mean it's your bad design, as you may be forced to work with a crappy library and cannot avoid the necessity of downcasting.

Like anything in software engineering, there is no perfect solution, and we will all have to downcast sometime or other. But just because we have to do it does not mean it is correct, or that the language should make it easy, or subtle, for us to do so. dynamic_cast<> was deliberately named to be as ugly as hell, and that's a *very good thing*. Other languages, e.g. C#, Java and, sadly, D at the moment, allow downcasting to fit unobtrusively into the code. (Of course C++ allows it also if you use C-style casts.)

I think D should force the use of a downcast() operator, which is both clear to the reader and unambiguously searchable by automatic tools.

Soapbox Sam

> Phill.
>
>
> "John Reimer" <jjreimer@telus.net> wrote in message news:pan.2004.01.23.14.14.58.592271@telus.net...
> > To set people straight here.  This code was a modified example of what
the
> > Java SWT GUI class does.  I posted it here so I could get help on how to work the code in D (trying to port this).  The real code tests using instanceof and then promptly downcasts if the object is found valid. Bad design? I really don't know if it is. But 99% chance that it is. :-)
> >
> > So it wasn't just me! I was just the unfortunate simpleton to choke on this candy.
> >
> > Later,
> >
> > John
>
>

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:busegu$26ce$1@digitaldaemon.com...
> > I dont see how testing to see if an Object
> > is an instanceof another Object BEFORE
> > downcasting can be bad in anyway, in fact, its
> > a bit like wearing a condom isnt it?
>
> There are two separate issues that you're commenting on here. If you're going to downcast, then it's certainly better to avoid doing a check
before
> and to have the success of the cast provide the information you require.

Sorry I meant it is good to check before, IF you are going to downcast. I
cant
see a problem with doing it this way can you?

================
if(obj instanceof(Button))
         then downcast;
else
     dont downcast;
--------------------------

Phill.

> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:busegu$26ce$1@digitaldaemon.com...
> > > I dont see how testing to see if an Object
> > > is an instanceof another Object BEFORE
> > > downcasting can be bad in anyway, in fact, its
> > > a bit like wearing a condom isnt it?
> >
> > There are two separate issues that you're commenting on here. If you're going to downcast, then it's certainly better to avoid doing a check
> before
> > and to have the success of the cast provide the information you require.
>
> Sorry I meant it is good to check before, IF you are going to downcast. I
> cant
> see a problem with doing it this way can you?
>
> ================
> if(obj instanceof(Button))
>          then downcast;
> else
>      dont downcast;
> --------------------------

Yes. First, it is more efficient to test and downcast in one go. I think C# would have it like

Button btn = obj as Button;
if(null != btn)
{
  // use button
}

Second, what do you do if you can't downcast? It's far better for your objects to utilise runtime polymorphism. It's clearer, generally more efficient and *much* more extensible.

I recognise that in GUIs and the like, it can be impossible to have an interface for all appropriate widgets but for "normal" programming you're often better re-examining the design.

Phill wrote:

>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
>news:busegu$26ce$1@digitaldaemon.com...
>  
>
>>>I dont see how testing to see if an Object
>>>is an instanceof another Object BEFORE
>>>downcasting can be bad in anyway, in fact, its
>>>a bit like wearing a condom isnt it?
>>>      
>>>
>>There are two separate issues that you're commenting on here. If you're
>>going to downcast, then it's certainly better to avoid doing a check
>>    
>>
>before
>  
>
>>and to have the success of the cast provide the information you require.
>>    
>>
>
>Sorry I meant it is good to check before, IF you are going to downcast. I
>cant
>see a problem with doing it this way can you?
>
>================
>if(obj instanceof(Button))
>         then downcast;
>else
>     dont downcast;
>--------------------------
>
>Phill.
>
>
>
>
>  
>
IF your going to downcast your going to test, why not do it in one go?

Button but = cast(Button)obj;
if (but)
{}

99% of the time your going to need to cast down if you need to test the type (please don't take that as advocating down casting) and your not saving any performance by checking first. Futhermore I hope this is not an argument for a new term, because if your only testing for type you can go:

if (cast(Button)obj)
{}

-- 
-Anderson: http://badmama.com.au/~anderson/

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:bush92$2akt$1@digitaldaemon.com...
> Phill wrote:
>
> >"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:busegu$26ce$1@digitaldaemon.com...
> >
> >
> >>>I dont see how testing to see if an Object
> >>>is an instanceof another Object BEFORE
> >>>downcasting can be bad in anyway, in fact, its
> >>>a bit like wearing a condom isnt it?
> >>>
> >>>
> >>There are two separate issues that you're commenting on here. If you're going to downcast, then it's certainly better to avoid doing a check
> >>
> >>
> >before
> >
> >
> >>and to have the success of the cast provide the information you require.
> >>
> >>
> >
> >Sorry I meant it is good to check before, IF you are going to downcast. I
> >cant
> >see a problem with doing it this way can you?
> >
> >================
> >if(obj instanceof(Button))
> >         then downcast;
> >else
> >     dont downcast;
> >--------------------------
> >
> >Phill.
> >
> >
> >
> >
> >
> >
> IF your going to downcast your going to test, why not do it in one go?
>
> Button but = cast(Button)obj;
> if (but)
> {}
>
> 99% of the time your going to need to cast down if you need to test the type (please don't take that as advocating down casting) and your not saving any performance by checking first. Futhermore I hope this is not an argument for a new term, because if your only testing for type you can go:
>
> if (cast(Button)obj)
> {}

I think if we're entertaining the notion of opExplicitCast, and even if we're not, we really need to have a separate operator for downcast, e.g.

    if (downcast(Button)obj)
    {}



That way any time you downcast readers of your code will know that you were downcast at the time. He he. (Apologies to any non-English / non-pompous readers. <g>)