Solved

Operator to obviate ((type)object).method()

Posted on 2003-12-06
24
291 Views
Last Modified: 2010-03-31
I recall about 18 months ago reading that the "next version" (back then) of Java would introduce an operator providing a more elegant way of doing this:

((type)object).method()

so that the cast applies to the object rather than the return value from its method.

Was this just some dream I had or is this actually coming?  Have I missed something since then that already replaces this?
0
Comment
Question by:AldenG
  • 10
  • 4
  • 4
  • +3
24 Comments
 
LVL 92

Expert Comment

by:objects
ID: 9890827
thats related to the order that things get evaluated, and I'm not aware of it changing.
0
 
LVL 92

Expert Comment

by:objects
ID: 9890831
you can always this if you want your code to be neater:

type typeobject = (type)object;
x = typeobject.method()
0
 
LVL 3

Expert Comment

by:monkesdb
ID: 9891273
dream
0
 
LVL 86

Accepted Solution

by:
CEHJ earned 50 total points
ID: 9891816
No - you were not dreaming ;-) You're probably thinking of generics, which are due to appear in 1.5:

http://java.sun.com/features/2003/05/bloch_qa.html

We are then meant to be able to do:

List<String> words = new ArrayList<String>();
String title = words.get(i).toUppercase(); // no cast required
0
 
LVL 16

Expert Comment

by:krakatoa
ID: 9892261
(((type)object)).method()

:)
0
 

Author Comment

by:AldenG
ID: 9892621
The addition of generics will certainly solve part of the problem and the link on 1.5 is interesting in several ways.

I suppose I was either recalling a dream or I failed to recognize some C++ programmer's wry joke.  While I don't remember precise details, I could swear I had seen something along the lines of introducing to Java a -> operator with precedence and associativity that would make the following work:

(type)object->method()   // (1)
(type)object->field          // (2)

and

object->(type)method()   // (3)
object->(type)field          // (4)

...where (1) and (2) cast the object before accessing its member, where (3) casts the value returned from the method and (4) simply casts the value of the field.  (I realize that's not quite how -> works in C++.)

Or maybe I miscontrued an earlier mention of generics or maybe I read someone else's misunderstanding of them.

Anyway, I'll leave the question open another few days before deciding points, but perhaps this was all a fig newton of my imagination.

0
 

Author Comment

by:AldenG
ID: 9892626
>  (((type)object)).method()

Krakatoa, I'm missing either your point or your joke.  Can you clue in this dim old brain of mine?
0
 
LVL 16

Expert Comment

by:krakatoa
ID: 9893593
>> Krakatoa, I'm missing either your point or your joke.  Can you clue in this dim old brain of mine?

Ah, well let me think ... yes, try compiling these two lines. ;)


System.out.println((String)(((Object)outstring).length()));

System.out.println(((String)((Object)outstring)).length());
0
 
LVL 16

Expert Comment

by:krakatoa
ID: 9893611
Then, to answer your next question, (which you haven't made yet) , try compiling these two, then compare what's going on with all 4 lines.

System.out.println((String)(((Object)outstring).toString()));

System.out.println(((String)((Object)outstring)).length());

:)
0
 
LVL 3

Expert Comment

by:monkesdb
ID: 9894706
krakatoa, it might be beneficial to read the converstation before you butt in.

(((type)object)).method();

is equivalent to

((type)object).mothod();

then you come up with some random example with random casts all over the place making no relavent conversation.
0
 
LVL 16

Expert Comment

by:krakatoa
ID: 9895328
>> krakatoa, it might be beneficial to read the converstation before you butt in.

Well that's really nice - thanks. Not.

I did read your question, and you are asking about how to cast the object rather than any object the object's method returns. If you understood anything about precedence, then you would understand what I am saying. Have you tried compiliing the lines I gave you, or are you just here to trade insults??

Moderator coming.





0
6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

 
LVL 16

Expert Comment

by:krakatoa
ID: 9897404
BTW my last comment should have made clearer that it is intended for monkesdb rather than the questioner.
0
 
LVL 16

Expert Comment

by:krakatoa
ID: 9897481
>> is equivalent to

((type)object).mothod();
<<


yeh; I think we all know that. The point of my posts was that the questioner seems to be having difficulty about precedence, because evidently it works other than he expects, hence my "casts all over the place" are meant to exemplify how that precedence works using brackets. It's exactly the same principle in a more condensed form, as objects' earlier comment.

(In fact the questioner had what he wanted from the start, which makes a good case for trying to explain it fully I would have thought).
0
 
LVL 5

Expert Comment

by:lwinkenb
ID: 9897812
I think you need to reread the question krakatoa...

The questioner isnt having trouble with casting precedence, rather he is asking if there is a more elegant way of writing:
((type)object).mothod();
0
 
LVL 16

Expert Comment

by:krakatoa
ID: 9898750
>> The questioner isnt having trouble with casting precedence ...

What role has elegance got in Java? I don't recognise it as a keyword. I think the questioner may be looking for more than the language can deliver at this point.

If you cast, the cast has to be pointed at an object - it's as simple as that. The questioner wants to know if the casting can be done on an object rather than on that object's method, if said method return an object. The answer is that a cast can be made on either, and so this question is just a case of calrifying precedence handling, since the questioner has a C++ background.
0
 
LVL 92

Expert Comment

by:objects
ID: 9899652
> I think the questioner may be looking for more than the language can deliver at this point.

Thats sort of what is being asked :)

> The questioner wants to know if the casting can be done on an object rather than on that object's method

No, s(he) asking if a new feature has or will be added to remove the need for the casting.
0
 

Author Comment

by:AldenG
ID: 9899685
Krak, I intend to try out your examples when I finish the task that holds my attention at present.  I have assumed that they  reveal something enlightening since you took the trouble to post them.  I also assume the results may bear some contemplation, and I try to minimize the multitasking in my life.  Hence my lack of response so far.

Since I hold an almost philosophical attachment to the value of serendipity, it's doesn't matter much to me how closely your riddle does or doesn't relate to my original question.  I just happen to be in the middle of something else at the moment.
0
 

Author Comment

by:AldenG
ID: 9899715
>  No, s(he) asking if a new feature has or will be added to remove the need for the casting.

More specifically, I think I was asking if there is a new or planned member-access operator with a lower precedence than a cast.  But I haven't though through every ramification to be sure that's exactly the essence of the question.
0
 
LVL 16

Expert Comment

by:krakatoa
ID: 9900173
>>  I just happen to be in the middle of something else at the moment.  ...

... fine .. you can read this whenever you get a moment. I have to post now, before I lose the plot completely.

 >> No, s(he) asking if a new feature has or will be added to remove the need for the casting. ...

This is akin to asking whether a new type of fuel will be developed that makes petrol obsolete. Yeh ... maybe ... but you'll still need to put some kind of fuel in.

When the object is stored in a container it's put in there (paradoxically "derefined" to continue the fuel analogy) by Java - meaning you the programmer dont need to get involved. But at some point that object needs to be refined - dereferenced, and that is the bit where you have to cast back. So it boils down more or less to a question of what stage you are prepared to do some work - Java cant perform miracles. If you want some convenience, then you have to accept the "inelegance" of casting when you come to work wiht the object again. To me, it would be difficult to see how much more "elegance" could be introduced to go beyond that already provided via parenthesising precedence, since, with a couple of bracket transpositions, you can access the other side of the coin so to speak. It would need a pretty fundamental advance of the entire paradigm to arrive at any marked increase in elegance, and until Turing's dream comes true, someone, somewhere, is going to have to get their hands dirty.

If a riddle still remains, it's what possible advantage would a non cast object access produce, and how would that be achieved, given that you need at some point to tell the environment what kind of object you really want this to be. ;)
0
 
LVL 16

Expert Comment

by:krakatoa
ID: 9900292
>> 12/07/2003 10:50AM PST ...

(type)object->method()   // (1)
(type)object->field          // (2)

and

object->(type)method()   // (3)
object->(type)field          // (4)

<<

in Java =
((type)object).method()||field //(1)+(2)
(type)(object.method()||field) //(3)+(4)

You could also:

(type)(((type)object).method());


0
 
LVL 3

Expert Comment

by:monkesdb
ID: 9908549
@admin
i purposely left the thread alone once i foresaw the arguement and i know that someone would put krak straight. Thanks objects.

@AldenG
if you are interested to find out what's happening in future versions of Java you should visit ...

http://jcp.org/en/jsr/all

... i found the list from the previous link by CEHJ. The list is massive and searching all of it would take an age, but i think the only thing close enough to what you would like is generics, they are going to be wickidcool.

but as far as threads go, i think this one is long past old age. put it to rest.

mdb
0
 
LVL 92

Expert Comment

by:objects
ID: 9908598
I don't think generics change much wrt this question.
In the case mentioned casting would still be required, though depending on usage you may be able to avoid declaring object as an Object and instead declare it as what it actually is.
0
 
LVL 16

Expert Comment

by:krakatoa
ID: 9910656
>> @admin
i purposely left the thread alone once i foresaw the arguement and i know that someone would put krak straight. Thanks objects.
<<

... one of the whackiest and most incorrect comments I've seen for a while.
0

Featured Post

Enabling OSINT in Activity Based Intelligence

Activity based intelligence (ABI) requires access to all available sources of data. Recorded Future allows analysts to observe structured data on the open, deep, and dark web.

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
IT Company 5 69
noX challenge 17 77
get weblogic logged in user in java 2 43
Java JRE greater than 1.6 5 24
An old method to applying the Singleton pattern in your Java code is to check if a static instance, defined in the same class that needs to be instantiated once and only once, is null and then create a new instance; otherwise, the pre-existing insta…
For beginner Java programmers or at least those new to the Eclipse IDE, the following tutorial will show some (four) ways in which you can import your Java projects to your Eclipse workbench. Introduction While learning Java can be done with…
Video by: Michael
Viewers learn about how to reduce the potential repetitiveness of coding in main by developing methods to perform specific tasks for their program. Additionally, objects are introduced for the purpose of learning how to call methods in Java. Define …
This tutorial covers a practical example of lazy loading technique and early loading technique in a Singleton Design Pattern.

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now