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

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?
AldenGAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

objectsCommented:
thats related to the order that things get evaluated, and I'm not aware of it changing.
0
objectsCommented:
you can always this if you want your code to be neater:

type typeobject = (type)object;
x = typeobject.method()
0
monkesdbCommented:
dream
0
Cloud Class® Course: SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
krakatoaCommented:
(((type)object)).method()

:)
0
AldenGAuthor Commented:
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
AldenGAuthor Commented:
>  (((type)object)).method()

Krakatoa, I'm missing either your point or your joke.  Can you clue in this dim old brain of mine?
0
krakatoaCommented:
>> 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
krakatoaCommented:
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
monkesdbCommented:
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
krakatoaCommented:
>> 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
krakatoaCommented:
BTW my last comment should have made clearer that it is intended for monkesdb rather than the questioner.
0
krakatoaCommented:
>> 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
lwinkenbCommented:
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
krakatoaCommented:
>> 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
objectsCommented:
> 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
AldenGAuthor Commented:
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
AldenGAuthor Commented:
>  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
krakatoaCommented:
>>  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
krakatoaCommented:
>> 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
monkesdbCommented:
@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
objectsCommented:
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
krakatoaCommented:
>> @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
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.