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)


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)


        


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?

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)


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


 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.
  

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.

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



it is taken to its next logical step. Fully supporting it enables



garbage collection, better debugger support, more automated



etc."

How is it supported in D? What features enable it? Is this visible to



programmer?  I haven't been able to see where the D language enables to
identify the type or class at runtime.

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

 token that they must be on guard for.

 Otherwise, it's going to be a disgusting sorry mess, reminiscent of Java

 RTTI-mad C++ (and yes, I _have_ perpetrated my fair share of evils in

 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
        



it is taken to its next logical step. Fully supporting it enables
        



garbage collection, better debugger support, more automated
        



etc."

How is it supported in D? What features enable it? Is this visible to
        



programmer?  I haven't been able to see where the D language enables to
identify the type or class at runtime.


        

ie object.classinfo.name

Sorry for shouting, but there must be one accepted way of performing downcasting, so that all programmers - especially newcomers - have a

token that they must be on guard for.

Otherwise, it's going to be a disgusting sorry mess, reminiscent of Java
    

RTTI-mad C++ (and yes, I _have_ perpetrated my fair share of evils in
    

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

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


 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

 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

 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?
      

going to downcast, then it's certainly better to avoid doing a check

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.

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?

going to downcast, then it's certainly better to avoid doing a check

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.

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?


          

going to downcast, then it's certainly better to avoid doing a check

and to have the success of the cast provide the information you require.


        

cant see a problem with doing it this way can you? ================ if(obj instanceof(Button)) then downcast; else dont downcast; -------------------------- Phill.

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

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






going to downcast, then it's certainly better to avoid doing a check

and to have the success of the cast provide the information you










cant
see a problem with doing it this way can you?

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

Phill.

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


downcast at the time. He he. (Apologies to any non-English / non-pompous
readers. <g>)


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:

      


could have downcast though as it's just a variant on cast. Not sure what you mean. Can you rephrase?

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?

going to downcast, then it's certainly better to avoid doing a check

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.

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