Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (803)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (867)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 3 4 [5] 6 7 8
  ignore  |  Print  
  Interesting proposals: Java 9 and beyond  (Read 104156 times)
0 Members and 1 Guest are viewing this topic.
Offline nsigma
« Reply #120 - Posted 2016-03-16 14:40:04 »

Thirdly, the diamond operator was previously invalid syntax, not just invalid code?  I think some of the Project Coin proposals were rejected on that basis.

Project Coin had a similar proposal to JEP 286 which used final.  In some ways that makes a lot more sense to me - if you want a variable you can assign to later you should be explicit about the type.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline KaiHH

JGO Kernel


Medals: 786



« Reply #121 - Posted 2016-03-16 14:41:30 »

Only one thing about type inference done too far: Haskell
Everything is totally type-safe (for the compiler) but absolutely not readable for a human.
Why? Because humans are not compilers and a human simply wants a type annotation every now and then to know what he/she is dealing with, instead of having to manually type-infer the whole program in his head (or hover over some text in some IDE to see what type it is).
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #122 - Posted 2016-03-16 14:47:17 »

I think Cas means this:

1  
2  
String x = (String) thing.foo();
String x = thing.foo();

If the compiler cannot figure out line 1 would result in a cast-exception at runtime, then removing the cast certainly won't move a compile-time error to a runtime error.

If the compiler can figure out line 1 would result in a cast-exception at runtime, then removing the cast certainly won't move a compile-time error to a runtime error, because the compiler knows this cast has to be done, and therefore will do the cast check on line 2.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline KaiHH

JGO Kernel


Medals: 786



« Reply #123 - Posted 2016-03-16 14:48:39 »

The thing is if the compiler can figure out that the explicit cast in line 1 would result in a cast-exception at runtime, then it would disallow the cast alltogether, because casting would not make any sense and would always result in an error.
Or maybe I did not get you.
Offline CommanderKeith
« Reply #124 - Posted 2016-03-16 14:57:36 »

Isn't widespread use of instanceof seen as an anti-pattern?

https://www.google.com.au/search?q=instanceof+antipattern

Offline nsigma
« Reply #125 - Posted 2016-03-16 14:57:49 »

1  
2  
String x = (String) thing.foo();
String x = thing.foo();


And as @KaiHH says, this has nothing to do with what the compiler can figure out and everything to do with what a human can figure out!  Looking at that code, line 2 tells me that thing.foo() always returns a String, line 1 says it might not.  These are semantically different.  I think the number of people who'll code that pattern by mistake will outnumber the number who want it!

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline Roquen

JGO Kernel


Medals: 518



« Reply #126 - Posted 2016-03-16 15:03:25 »

instanceof is a sign of code-smell on one hand, but like unstructured gotos in C is a lifesaver is some cases as well.  So it goes. (polymorphic call-site with high probability of a given target).
Offline princec

« JGO Spiffy Duke »


Medals: 1136
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #127 - Posted 2016-03-16 15:03:39 »

If I write
1  
String x = (String) thing.foo();

then I am already asserting that thing.foo() always returns a String even it it is declared to return an Object (remember - ClassCastExceptions are exceptions - no normal program flow should ever explicitly rely on exceptions!)

As x can only ever contain a String, why do I need to assert it twice?

Cas Smiley

Offline nsigma
« Reply #128 - Posted 2016-03-16 15:18:27 »

then I am already asserting that thing.foo() always returns a String even it it is declared to return an Object

You're asserting it for certain circumstances / certain state of your project.  If that's always the case and thing.foo() is your code, rewrite thing.foo()!  Otherwise, that's not the same assertion.

My point is really the opposite - in line 2 you're not asserting anything.  It's equally likely that people write that code as a mistake.  Now, the compiler will flag that as an error.

Quote from: CommanderKeith
Isn't widespread use of instanceof seen as an anti-pattern?

I'm generally of the opinion that single use of instanceof or casting (eg. not a chain of if statements) is fine on occasion and better than the convoluted crap people sometimes write just because they've heard they shouldn't use it!   persecutioncomplex  It's a useful workaround to Java not having double dispatch.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline KaiHH

JGO Kernel


Medals: 786



« Reply #129 - Posted 2016-03-16 15:20:37 »

I also agree with @nsigma.
I can only think of one reason why an explicit cast is necessary here: To pat the programmer on the back of his hand and saying "You need a cast here? Probably your class model/data structure is not right."
Whenever you need to cast, it is (mostly) bad. Be it implicit or explicit. I think it is meant to hint the programmer to that.
Doing an explicit cast then makes the compiler step out of the way by saying: "But I warned you!"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #130 - Posted 2016-03-16 15:56:58 »

If I write
1  
String x = (String) thing.foo();

then I am already asserting that thing.foo() always returns a String even it it is declared to return an Object (remember - ClassCastExceptions are exceptions - no normal program flow should ever explicitly rely on exceptions!)

As x can only ever contain a String, why do I need to assert it twice?

Cas Smiley
With this it'd be extremely easy to accidentally cast something without the intention of doing so, and there's no warning or indicator of it happening. I'm against this for the same reason I'm against var: it obfuscates the code needlessly.

Myomyomyo.
Offline Hydroque

JGO Coder


Medals: 25
Exp: 5 years


I'm always inspiring a good time.


« Reply #131 - Posted 2016-03-16 16:34:07 »

With this it'd be extremely easy to accidentally cast something without the intention of doing so, and there's no warning or indicator of it happening. I'm against this for the same reason I'm against var: it obfuscates the code needlessly.
Actually, while you're correct, I think the attention should go to this:

1  
2  
3  
4  
5  
String var = (String) object.foo();

// versus

String var = (String) object.foo().bar();


As you can see, the first one is just the normal cast, but the second one is an extended cast, where bar would return an object. The left hand and right hand operands are completely seperate. String var; is the accessor of the object.

You think I haven't been monitoring the chat? http://pastebin.java-gaming.org/c47d35366491fHere is a compilation <3
Offline theagentd
« Reply #132 - Posted 2016-03-16 16:49:06 »

1  
2  
3  
4  
5  
String var = (String) object.foo();

// versus

String var = (String) object.foo().bar();


As you can see, the first one is just the normal cast, but the second one is an extended cast, where bar would return an object. The left hand and right hand operands are completely seperate. String var; is the accessor of the object.

I have no idea what point you're trying to make here. Those two are completely different things, where at the end you cast the result to a String.


Examples of things that can go wrong with implicit casting:

 -
int anInt = aFloat;
Accidental rounding, JGO would be flooded with "why is my aspect ratio wrong?
float aspect = width/height;
"-like problems.
 - Overloaded functions would completely break in many applications because most things can be cast to most things all of a sudden.
 - You could easily get away with an ArrayList without any generics and nobody would know what the list is used for.

I for one am in favour of forcing people to be clear with their intentions, especially when the cost is to type "int" instead of "var" in front of variable declarations, or having to cast variables so you at least feel a bit guilty for doing it instead of being able to pretend that everything's fine.

The only thing time implicit casts would be okay would be inside an if(instanceof)-block. Frankly, why not just update the type of the object tested if it can be proven to be that type within a block?

1  
2  
3  
if(x instanceof String){
    //Inside here x is a String.
}

Myomyomyo.
Offline nsigma
« Reply #133 - Posted 2016-03-16 16:58:38 »

The only thing time implicit casts would be okay would be inside an if(instanceof)-block. Frankly, why not just update the type of the object tested if it can be proven to be that type within a block?

1  
2  
3  
if(x instanceof String){
    //Inside here x is a String.
}


Try reading the example I posted earlier and the link to the Project Coin mailing list archives.  One reason your suggestion was rejected relates to overloaded methods -

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
void doSomething(Object s) {}

void doSomething(String s) {}

//

if (x instanceof String) {
    //Inside here x is a String.
  doSomething(x); // oops, we've changed behaviour!
}




Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline princec

« JGO Spiffy Duke »


Medals: 1136
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #134 - Posted 2016-03-16 16:59:45 »

You can't compare primitive conversion with type narrowing as they are totally different priniciples. Primitive conversion actually changes the representation of the data. Type narrowing is simply an assertion for the compiler.

Again I ask you:

What extra do you bring to the table when you do:
1  
String var = (String) object.foo();

over
1  
String var = object.foo();

that is not both explicit and implicit already in the code?

Remember an illegal cast is still an illegal cast: if foo() returns an Integer it cannot be cast to String and the compiler will reject the code. If foo() returns any supertype of String (only Object in this case) then why must I write String twice? C'mon, you're not making clear what this "potential confusion" could possibly be.

Cas Smiley

Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #135 - Posted 2016-03-16 17:06:55 »

The thing is if the compiler can figure out that the explicit cast in line 1 would result in a cast-exception at runtime, then it would disallow the cast alltogether, because casting would not make any sense and would always result in an error.
Or maybe I did not get you.
You actually got my point: it doesn't change anything, because the compiler can infer everything already, and already does so - which means it's a compile-time error. The new syntax won't trade off compile-time errors for runtime-errors.


Note that I'm not actually in favor of the above (it certainly is a sign of code smell) - I'm just defending the point that it does not change anything.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline theagentd
« Reply #136 - Posted 2016-03-16 17:21:46 »

@Cas

Most likely the only one who knows that object.foo() always returns a String despite being declared Object is the person who wrote the code. The entire thing is easily solved by extending the class and overriding the function to explicitly return String. If you choose not to do that and hack around it, I WANT TO KNOW THAT. Any time you need to cast like that it implies that there's lots of obfuscated information the programmer didn't explicitly code in about how the program works and the data is used. To answer your question, the information that is lost is that object.foo() actually returns a value other than String, but you're casting it to that. That's not clear without knowing how foo() works in the first place.

Myomyomyo.
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #137 - Posted 2016-03-16 18:01:07 »

I know this topic is quite a bit older but it might still be interesting to somebody. Just gave a talk about the after-unsafe area and in-flight proposals. Obviously lots of information share the same base as the original post on infoq, anyhow the slidedeck has some more details in certain parts and will be updated more frequently when new proposals come around: http://de.slideshare.net/ChristophEngelbert/a-postapocalyptic-sunmiscunsafe-world

PS: What's your opinion on JEP 286? http://openjdk.java.net/jeps/286 Did you vote already, if not please do, last day: https://www.surveymonkey.com/r/KGPTHCG
very interesting! thank you very much Smiley

wait .. did I just read about primitive generics ?
Offline KaiHH

JGO Kernel


Medals: 786



« Reply #138 - Posted 2016-03-16 18:02:48 »

Try reading the example I posted earlier and the link to the Project Coin mailing list archives.  One reason your suggestion was rejected relates to overloaded methods -

...code snip...
Wow, very nice argument! Thanks!
Offline princec

« JGO Spiffy Duke »


Medals: 1136
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #139 - Posted 2016-03-16 19:53:33 »

@Cas

Most likely the only one who knows that object.foo() always returns a String despite being declared Object is the person who wrote the code. The entire thing is easily solved by extending the class and overriding the function to explicitly return String. If you choose not to do that and hack around it, I WANT TO KNOW THAT. Any time you need to cast like that it implies that there's lots of obfuscated information the programmer didn't explicitly code in about how the program works and the data is used. To answer your question, the information that is lost is that object.foo() actually returns a value other than String, but you're casting it to that. That's not clear without knowing how foo() works in the first place.

I'm pretty sure the callsite also knows that it always returns a String, because that's what the code asserts. Twice.

Cas Smiley

Offline CopyableCougar4
« Reply #140 - Posted 2016-03-16 20:13:13 »

I can't imagine too many instances where you should need to perform a cast like this:

1  
String x = (String) thing.foo();


IMHO most organized code should either return an interface/abstraction with all of the necessary methods to call or only return a specific type.

Either wandering the forum or programming. Most likely the latter Smiley

Github: http://github.com/CopyableCougar4
Offline princec

« JGO Spiffy Duke »


Medals: 1136
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #141 - Posted 2016-03-16 20:26:00 »

Admittedly since the advent of generics, casts are vastly rarer than they used to be in real code.

Cas Smiley

Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Reply #142 - Posted 2016-03-17 14:22:56 »

noctarius, it's still unclear to me how VarHandle and MemoryRegion drive sun.misc.Cleaner useless. How can I decide when I want to free the native resources used by a direct NIO byte buffer?

Same state as last time, still no proposal to make this predictably freed. I'm also still waiting to see how this will work. AutoClosable would A way, probably not the best though.

Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Reply #143 - Posted 2016-03-17 14:36:02 »

I know this topic is quite a bit older but it might still be interesting to somebody. Just gave a talk about the after-unsafe area and in-flight proposals. Obviously lots of information share the same base as the original post on infoq, anyhow the slidedeck has some more details in certain parts and will be updated more frequently when new proposals come around: http://de.slideshare.net/ChristophEngelbert/a-postapocalyptic-sunmiscunsafe-world

PS: What's your opinion on JEP 286? http://openjdk.java.net/jeps/286 Did you vote already, if not please do, last day: https://www.surveymonkey.com/r/KGPTHCG
very interesting! thank you very much Smiley

wait .. did I just read about primitive generics ?

Type specialization but yeah it kind of ends up in the same result + the specialized type will have the type information (as far as it looks at the moment, no type erasure as with generics) Smiley It most probably will finally be fixed (if you consider it a bug - I do Cheesy)

Offline Roquen

JGO Kernel


Medals: 518



« Reply #144 - Posted 2016-03-17 15:07:24 »

Don't get me started on type-eraser.  Although there are some evil tricks it allows.
Offline princec

« JGO Spiffy Duke »


Medals: 1136
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #145 - Posted 2016-03-17 16:00:14 »

Didn't I hear that type erasure may eventually go as well and we'd get those "fully reified types" all the cool kids go on about?

Cas Smiley

Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Reply #146 - Posted 2016-03-17 16:05:34 »

Didn't I hear that type erasure may eventually go as well and we'd get those "fully reified types" all the cool kids go on about?

Cas Smiley

With type specialization the type will be branded into the class itself whenever the classloader / JVM has to spin a specialized version of the template class. Therefore it will look like type erasure goes away. I really hope generics will be completely reworked to type specialization but I have no overview of the impact on old code, so probably not =(

Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #147 - Posted 2016-03-17 17:45:27 »

Non-final static fields will be treated differently, as each (specialized) class will have its own static fields, unless they decide not to copy them during specialization.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Reply #148 - Posted 2016-03-17 20:42:18 »

Non-final static fields will be treated differently, as each (specialized) class will have its own static fields, unless they decide not to copy them during specialization.

Oh really, they're copied? Seems like I missed that part. Thanks!

Offline theagentd
« Reply #149 - Posted 2016-03-17 21:04:17 »

With type specialization the type will be branded into the class itself whenever the classloader / JVM has to spin a specialized version of the template class. Therefore it will look like type erasure goes away. I really hope generics will be completely reworked to type specialization but I have no overview of the impact on old code, so probably not =(
So basically if I type ArrayList<int> it'll actually create int[]s instead of Integer[]s internally?! COUNT ME IN!!!

Myomyomyo.
Pages: 1 ... 3 4 [5] 6 7 8
  ignore  |  Print  
 
 

 
Riven (397 views)
2019-09-04 15:33:17

hadezbladez (5280 views)
2018-11-16 13:46:03

hadezbladez (2204 views)
2018-11-16 13:41:33

hadezbladez (5544 views)
2018-11-16 13:35:35

hadezbladez (1150 views)
2018-11-16 13:32:03

EgonOlsen (4584 views)
2018-06-10 19:43:48

EgonOlsen (5462 views)
2018-06-10 19:43:44

EgonOlsen (3119 views)
2018-06-10 19:43:20

DesertCoockie (4015 views)
2018-05-13 18:23:11

nelsongames (4708 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!