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