www.digitalmars.com         C & C++   DMDScript  

D - Java instanceof?

reply John Reimer <jjreimer telus.net> writes:
I'm trying to figure out how to do the equivalent of Java instanceof in D.
Is anybody familiar with how to do it? It should be possible.

sample:

java :

class Square {
	int x,y;

	public boolean equals (Object object) {
		if (object instanceof Square) {
			Square p = (Square)object;
			p.x = this.x; 
			p.y = this.y;
			return true;
		}
		return false;
	}
}
Jan 22 2004
next sibling parent reply John Reimer <jjreimer telus.net> writes:
 
 class Square {
 	int x,y;
 
 	public boolean equals (Object object) {
 		if (object instanceof Square) {
 			Square p = (Square)object;
 			p.x = this.x;
 			p.y = this.y;
 			return true;
 		}
 		return false;
 	}
 	}


A little mistake here, but the question still is valid. Lines with
p.x, p.y, and "return true" should be replaced with the following: 

return (p.x == this.x) && (p.y == this.y);
Jan 22 2004
parent reply Vathix <vathix dprogramming.com> writes:
John Reimer wrote:

class Square {
	int x,y;

	public boolean equals (Object object) {
		if (object instanceof Square) {
			Square p = (Square)object;
			p.x = this.x;
			p.y = this.y;
			return true;
		}
		return false;
	}
	}


 
 
 A little mistake here, but the question still is valid. Lines with
 p.x, p.y, and "return true" should be replaced with the following: 
 
 return (p.x == this.x) && (p.y == this.y);



Cast to the type and check for null:

Square p = cast(Square)object;
if(p) { is instance } else { is not }
Jan 22 2004
next sibling parent John Reimer <jjreimer telus.net> writes:
 
 Cast to the type and check for null:
 
 Square p = cast(Square)object;
 if(p) { is instance } else { is not }


Hmmm... that's it?

Much appreciated! :)
Jan 22 2004
prev sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
If cast() fails, it will return null?  Or do you need a try/catch?

Vathix wrote:


 John Reimer wrote:
 

 class Square {
     int x,y;

     public boolean equals (Object object) {
         if (object instanceof Square) {
             Square p = (Square)object;
             p.x = this.x;
             p.y = this.y;
             return true;
         }
         return false;
     }
     }




 A little mistake here, but the question still is valid. Lines with
 p.x, p.y, and "return true" should be replaced with the following:
 return (p.x == this.x) && (p.y == this.y);


 
 
 
 Cast to the type and check for null:
 
 Square p = cast(Square)object;
 if(p) { is instance } else { is not }
Jan 22 2004
parent reply Vathix <vathix dprogramming.com> writes:
Brad Anderson wrote:


 If cast() fails, it will return null?  Or do you need a try/catch?
 



Just returns null.
Jan 22 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Vathix wrote:


 Brad Anderson wrote:


 If cast() fails, it will return null?  Or do you need a try/catch?


 Just returns null.


BTW: In C++ you'd have to use dynamic_cast<Square>(object)

-- 
-Anderson: http://badmama.com.au/~anderson/
Jan 22 2004
parent reply John Reimer <jjreimer telus.net> writes:
 
 BTW: In C++ you'd have to use dynamic_cast<Square>(object)
 


That's an interesting point. D way seems so much simpler. :)
Jan 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 BTW: In C++ you'd have to use dynamic_cast<Square>(object)


 That's an interesting point. D way seems so much simpler. :)


How do you work that? It's the same number of expressions/line. And the C++
is *far* clearer in highlighting that something nasty is happening by the
intentionally ugly dynamic_cast<>
Jan 23 2004
parent reply John Reimer <jjreimer telus.net> writes:
On Fri, 23 Jan 2004 21:36:53 +1100, Matthew wrote:


 

 BTW: In C++ you'd have to use dynamic_cast<Square>(object)


 That's an interesting point. D way seems so much simpler. :)


 
 How do you work that? It's the same number of expressions/line. And the
 C++ is *far* clearer in highlighting that something nasty is happening by
 the intentionally ugly dynamic_cast<>


I don't know how I worked that! It may sound amazing, but it all just came
to me on some whim! :D

Apparently, from inexperience, I assumed that the D way of doing
this was simple AND safe because of some technological marvel. If this is
not the case, then you'll have to educate me.  My memory likely is in bad
need of refreshing.

For some reason I thought downcasting evils were limited to the convoluted
C++ language because of all it's old appendages.

Okay?
Jan 23 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
John Reimer wrote:


On Fri, 23 Jan 2004 21:36:53 +1100, Matthew wrote:

  


BTW: In C++ you'd have to use dynamic_cast<Square>(object)


        


That's an interesting point. D way seems so much simpler. :)
      


How do you work that? It's the same number of expressions/line. And the
C++ is *far* clearer in highlighting that something nasty is happening by
the intentionally ugly dynamic_cast<>
    


I don't know how I worked that! It may sound amazing, but it all just came
to me on some whim! :D

Apparently, from inexperience, I assumed that the D way of doing
this was simple AND safe because of some technological marvel. If this is
not the case, then you'll have to educate me.  My memory likely is in bad
need of refreshing.

For some reason I thought downcasting evils were limited to the convoluted
C++ language because of all it's old appendages.

Okay?




  


A dynamic cast needs t be done at runtime (performance hit) and can 
change the pointer location to null.  When ever you have a dynamic cast 
(and only use it when nessary), you'll also need to check if the 
variable is null.

-- 
-Anderson: http://badmama.com.au/~anderson/
Jan 23 2004
parent John Reimer <jjreimer telus.net> writes:
 A dynamic cast needs t be done at runtime (performance hit) and can change
 the pointer location to null.  When ever you have a dynamic cast (and only
 use it when nessary), you'll also need to check if the variable is null.


Ok.  I would think it would be important to check if the variable was
null anyway before casting.  

In fact, checking if the pointer changed to
null was the whole point of finding out if "object" was the same class as
square.  If it changes to null during the cast, then it isn't a square. 
Otherwise, it is.

That's why I asked if this is the only RTTI ability that D has.
Jan 23 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 On Fri, 23 Jan 2004 21:36:53 +1100, Matthew wrote:


 BTW: In C++ you'd have to use dynamic_cast<Square>(object)


 That's an interesting point. D way seems so much simpler. :)


 How do you work that? It's the same number of expressions/line. And the
 C++ is *far* clearer in highlighting that something nasty is happening




by

 the intentionally ugly dynamic_cast<>


 I don't know how I worked that! It may sound amazing, but it all just came
 to me on some whim! :D

 Apparently, from inexperience, I assumed that the D way of doing
 this was simple AND safe because of some technological marvel. If this is
 not the case, then you'll have to educate me.  My memory likely is in bad
 need of refreshing.

 For some reason I thought downcasting evils were limited to the convoluted
 C++ language because of all it's old appendages.


Downcasting is evil whatever the language. It always (i.e. 99.9% of the
time) indicates bad design, either on the part of the programmer (in your
motivating case), or the language designer (the whole of Java / .NET), and
if you find yourself using it you should question whether you're in the 0.1%
area of the design-quality graph.


 Okay?


Always okay, John, me old buddy! :)
Jan 23 2004
prev sibling parent Sjoerd van Leent <Sjoerd_member pathlink.com> writes:
Brad Anderson says


 If cast() fails, it will return null?  Or do you need a try/catch?


Maybe a construct can be made that supports throwing an exception. This would be
in the form:

try {
<instance2> = safeCast(<class2>)<instance1>;
} catch (ClassCastException e) {
..
}

Though it could also be done using a template I think.

Regards,
Sjoerd van Leent
Jan 23 2004
prev sibling next sibling parent reply John Reimer <jjreimer telus.net> writes:
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.
Jan 23 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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

Check out:
http://www.digitalmars.com/d/phobos.html#object

The only real documentation is in object.d.

-- 
-Anderson: http://badmama.com.au/~anderson/
Jan 23 2004
next sibling parent John Reimer <jjreimer telus.net> writes:
  

 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, that's what I needed to know.  I did some searching on this
newsgroup too and noticed some vague references to it.
Jan 23 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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)


 Check out:
 http://www.digitalmars.com/d/phobos.html#object

 The only real documentation is in object.d.
Jan 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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
Jan 23 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Jan 23 2004
prev sibling parent John Reimer <jjreimer telus.net> writes:
 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
Jan 23 2004
prev sibling parent reply John Reimer <jjreimer telus.net> writes:
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
Jan 23 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 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
Jan 23 2004
parent John Reimer <jjreimer telus.net> writes:
 
 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.
Jan 23 2004
prev sibling parent reply "Phill" <phill pacific.net.au> writes:
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
Jan 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 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

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
Jan 23 2004
parent reply "Phill" <phill pacific.net.au> writes:
"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.
Jan 23 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 "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;
 --------------------------



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.
Jan 23 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Jan 23 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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>)
Jan 23 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:


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

  


Furthermore I hope this is not an argument for a new term. <- What I meant by
that was instanceof is a different from casting, and less powerful. You could
have downcast though as it's just a variant on cast.

<g> Even being an Australian English speaker I trouble understanding you 
some times ;)

-- 
-Anderson: http://badmama.com.au/~anderson/
Jan 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:busj7q$2dlj$1 digitaldaemon.com...

 Matthew wrote:


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


 Furthermore I hope this is not an argument for a new term. <- What I meant


by that was instanceof is a different from casting, and less powerful. You
could have downcast though as it's just a variant on cast.

Not sure what you mean. Can you rephrase?


 <g> Even being an Australian English speaker I trouble understanding you
 some times ;)


Such is my burden. :)


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





 Jan 23 2004



  parent  J Anderson <REMOVEanderson badmama.com.au>  writes:


Matthew wrote:


      


Furthermore I hope this is not an argument for a new term. <- What I meant
    


by that was instanceof is a different from casting, and less powerful. You
could have downcast though as it's just a variant on cast.

Not sure what you mean. Can you rephrase?

  


with
obj instance of(Square)

All you get back is a Boolean value. It's different from casting, with 
different rules and form.

cast(Square) obj;
downcast(Square) obj;

The form is the same, and the meaning is almost the same, it's really 
only a change of words.  Of course they wouldn't be interchangeable in 
most cases but downcast less of a burden on the programmer to learn then 
instanceof, which is also less functional.


<g> Even being an Australian English speaker I trouble understanding you
some times ;)
    


Such is my burden. :)
  

  


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




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



 Jan 24 2004



prev sibling  parent  "Phill" <phill pacific.net.au>  writes:


Sorry guys I was thinking in Java

In Java as you know you cant
if(Object)
it takes and returns a boolean value true
or false.

So probably a quicker way than the first way
I mentioned, would be to downcast
in a  try and catch the exception if it occurs.

non-pompous Aussie. :o)


"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)
 {}

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





 Jan 23 2004