Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (524)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (592)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 [3] 4 5 6
  ignore  |  Print  
  Java 7 to get Closures!  (Read 22533 times)
0 Members and 1 Guest are viewing this topic.
Offline Spasi
« Reply #60 - Posted 2009-11-22 22:53:51 »

Well, you're wrong. The JIT seems to know how to inline methods pretty well, so once it inlined everything into everything, there is a fair chance that even that 'last' object does not escape the 'new' current context.
You're correct, but I was thinking something like
1  
this.vec = (v add v2 mul v3 div 2).normalize();
for the sake of his argument. In a case like that one instance does escape.
Online princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #61 - Posted 2009-11-22 23:15:33 »

and the few objects that do escape are going to get mopped up by the increasingly sophisticated garbage collection going on. It's all good stuff Smiley

Cas Smiley

Offline DzzD
« Reply #62 - Posted 2009-11-22 23:19:11 »

Which is what Java has been doing all along for us on many other fronts.
It does a lot of optimisation but I wont say it does it soooo well (a simple exemple is arrays bounds check where it just doesn't do any (enought) even
if you acces array in a stupid loop (for i<a.length), you cannot rely 100% on it (or without thinking of what's going on in the background)
abstracting more will just make it harder to get rids of certain bugs.

It has to be said though that EA is not actually here yet, except in Excelsior JET. BTW has anyone here tried it recently? I used it back in v3.5 days or so and it was utterly, blindingly fast compared to the Sun JREs of the day (2003 or so, 1.4.2)
I used (just few tests) it too some years ago, dont remember wich release, and in fact it was making application a bit faster : but as I remember it also
allow strong optimisation as arrays bounds check remove and also take age to compile. EA ofcourse will optimize ( it is its first goal no ? ) but above optimisation is just sometime impossible.

I really think that complexification of the language is not requiered ( wont really change our life or make java more simple / readable ) and is not a good way and that it wont serve Java (and I already think that Generics just sucks too...)

some primary goal was to be ... Simple & have High Performance :  http://java.sun.com/docs/white/langenv/Intro.doc2.html two things that are going away with all thoses new features added every days.

I wonder why at first they only overload one operator (+) for the String cast ? anyone know ?

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline DzzD
« Reply #63 - Posted 2009-11-22 23:19:50 »

and the few objects that do escape are going to get mopped up by the increasingly sophisticated garbage collection going on. It's all good stuff Smiley

Cas Smiley

are you really going to forget  abut object pooling ? in any case ?

EDIT:  just want to add this one ... Cry as I see Jave &  JRE becoming every day more and more bug full and there is so much entousiasme/support around this ... that's too sad

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #64 - Posted 2009-11-22 23:34:11 »

It has to be said though that EA is not actually here yet, except in Excelsior JET. BTW has anyone here tried it recently? I used it back in v3.5 days or so and it was utterly, blindingly fast compared to the Sun JREs of the day (2003 or so, 1.4.2)
I got in their 5.0 beta a couple of years ago and tried it with Snowman Village, and performance seemed about identical (although obviously there wasn't any JIT warmup, which is a big plus). Although it wasn't a particularly CPU hungry game so I'm not sure how fair a comparison it was.

A big thumbs up for their tools though - they've got a nice gui app where you point it at your jars and set a few config flags and it'll spit out an exe that pretty much worked straight away. It's a shame it's so pricey ($1200 for the basic version) since it seems like a really good product.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline kaffiene
« Reply #65 - Posted 2009-11-23 00:19:37 »


arrrg, you'r crazy ! dont do that
operator overloading is nice sometime but I think that it maybe confusing in many many case.

I find pretty nice to use somthing like the following that let me write easy undertadable code :

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public Vector add(Vector v)
{
 x+=v.x etc...
 retur this;
}

public Vector mul(double m)
{
 x*=m etc...
 retur this;
}

//then you can write things like below wich I found are less confusing, and with one you are not limited by the number of operators :
v.add(v2).mul(v3).div(2).normalize()


you simply have to read from left to right (no operator priority problem)
[/quote]


Yup, I personally use that style and find it works great.  "c = a.plus(b)" is just as readable as "c = a + b", BUT it has the added bonus that when I see it, I know that 'a' is a class, 'plus' is a method and I know where to go to find the definition.  With overloading as in C++, when I see "c = a + b" and I can't tell if these are classes, primitives, or indeed what the line means.  Without reading all the code to find out whether something has overloaded this operation, I can't tell what the lines means (or even where to go to find out)
Offline DzzD
« Reply #66 - Posted 2009-11-23 00:32:46 »

Yup, I personally use that style and find it works great.  "c = a.plus(b)" is just as readable as "c = a + b", BUT it has the added bonus that when I see it, I know that 'a' is a class, 'plus' is a method and I know where to go to find the definition.  With overloading as in C++, when I see "c = a + b" and I can't tell if these are classes, primitives, or indeed what the line means.  Without reading all the code to find out whether something has overloaded this operation, I can't tell what the lines means (or even where to go to find out)
Smiley cool

and not to mention it is homogeneous (between unary opertors or multiple one)

I can do :
1  
vtmp.copy(v0).rotateX(0.5).rotateY(0.1).add(v2).normalize()


and continue in the same way :
1  
vtmp.copy(v0).rotateX(0.5).rotateY(0.1).add(v2).normalize().add(v3).mul(2).rotateXYZ(0.5,0.5,0.1)


EDIT : and also that you get each operator in code completion every time you type "." in the above line




Offline CommanderKeith
« Reply #67 - Posted 2009-11-23 03:43:03 »

It has to be said though that EA is not actually here yet, except in Excelsior JET. BTW has anyone here tried it recently? I used it back in v3.5 days or so and it was utterly, blindingly fast compared to the Sun JREs of the day (2003 or so, 1.4.2)

Cas Smiley

EA's in java 7 and Sun have said it will be backported to java 6 too. It's already been included in the JRE 6 u14 distribution (http://java.sun.com/javase/6/webnotes/6u14.html) and can be turned on using an optional flag. I tried it and saw a speed up of about 15% in my app. I don't think it's in the latest JRE 6 u17, hopefully it will get re-included soon.

Offline OverKill

Junior Devvie




Java games rock!


« Reply #68 - Posted 2009-11-23 08:31:08 »

@C#:
In the beginning they had added a lot of stuff from the community wish list, thus my comparison with C++.
Though I have no idea how stable (feature change wise ) it is ATM.

@ operator overloading:
+1 against operator overloading (or -1 for operator overloading ?)

While it is a nice feature, it can introduce a lot of headache when that + does not really do what you think it does.
Naturally this is just a question of misusing the feature, but sadly people can and will, so I'd rather no see it.

It is kinda like the defines in C/C++.
A great tool that can really be helpful, but Evil when people start misusing it, as in my example above.

(actually, both are features I miss in Java, but they do not belong in Java)

As someone mentioned before, the nice thing about Java is you can just look at the code and know, that it will exactly what it states.
No hidden defines, no overloaded operators.
Online princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #69 - Posted 2009-11-23 09:30:19 »

Yes, operator overloading sucks, but what about being able to define operator methods as per my suggestion...? Easily readable, minimal syntactical update, no confusion, all the benefits...

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #70 - Posted 2009-11-23 10:31:54 »

Every VM uses primitive data types but these are usually hidden away in VM code and not accessed directly like you do in Java. It's the compiler and not the VM that does this kind of optimization and decides when it's safe to convert an object reference to a VM internal data type, but this would only be visible if you looked inside the generated VM code.

A compliant ahead-of-time compiler may not perform transforms across compilation-units. Transforming wrapped primatives would have to happen at runtime. And even inside a CU these types of transforms are hairy.  One cannot statically know if some other CU may call the method in question.  Therefore any transformed method would have to be replicated...and potentially multiple time depending on the number of wrapped primative parameters.

WRT: Operator overloading

To be clear, I'm not advocating adding operator overloading to Java.  I simply find the "bad programming" argument very weak.

To quote myself:
Quote
When the number of operations is small, it doesn't really matter, when large..it's a really issue.

All the examples given are trivally short and easy to read.  When I really want operator overloading is for things like: implement a higher precision float library and build basic operations of top of that (vector analysis, linear alg., ortho-polys, etc) and/or multi-element algebras.  When a given method has hundreds of algebraic operations, readability becomes a real issue.

1  
this.vec = (v add v2 mul v3 div 2).normalize();


Add some colons and flip the normalize to the front and you have SmallTalk. Wink
Online pjt33
« Reply #71 - Posted 2009-11-23 12:06:46 »

To quote myself:
All the examples given are trivally short and easy to read.  When I really want operator overloading is for things like: implement a higher precision float library and build basic operations of top of that (vector analysis, linear alg., ortho-polys, etc) and/or multi-element algebras.  When a given method has hundreds of algebraic operations, readability becomes a real issue.
If operator overloading is added then ITSM that it should be reserved for algebraic objects: not full fields (as then it wouldn't be usable for matrices) but at least structures in which all four of the overloaded operators (+-*/) make sense. Modulus doesn't make sense except for numbers, so isn't included.

I think you'd have to use F-bounded polymorphism, though, which might make it unpopular. Sample interface, so that people can complain about the generics Cheesy
1  
2  
3  
4  
5  
6  
7  
public interface OpOverloadObject<T extends OpOverloadObject<T>>
{
    public T add(T addend);
    public T subtract(T minuend);
    public T times(T multiplicand);
    public T divide(T divisor);
}
The F-bound is kept simple deliberately. The method names are spelt out in full to avoid changing the parser. It should probably be in the contract that (a+b)-b = (a-b)+b = a algebraically (although obviously error is permitted) and similarly (a*b)/b = (a/b)*b algebraically unless the division results in ArithmeticException.
Offline OverKill

Junior Devvie




Java games rock!


« Reply #72 - Posted 2009-11-23 12:34:33 »

@Bad programmer code:
Let's be honest here. *Every* code not written by oneself is 'bad programmer code'.
You'd be surprised how people can really butcher a language.

Yes, operator overloading sucks, but what about being able to define operator methods as per my suggestion...? Easily readable, minimal syntactical update, no confusion, all the benefits...

Cas Smiley
Though I did not find DzzD's version hideous, it could be cool.

I also see how this could still be messy if you have, say two different Vector classes.
Say Vector2d and Vector3d (an example, don't taze me, bro Cheesy ).

Then you'd have to be more exact again.
(v Vector2d.add v2 Vector2d.mul v3 Vector2d.div 2).normalize();
or?

Not to mention the icky VB.net feeling I get when looking at it. Wink
(ye olde, is that a comment or a method call with parameters?)

I see what you mean, but I honestly do not really see the benefits.
Yet I'd still prefer DzzD's version. If not for the only fact that no changes would be needed.
Offline Roquen
« Reply #73 - Posted 2009-11-23 13:23:37 »


@pjt33: Limiting the set of operators doesn't make sense to me. This ignores non-primative scalar types for instance. Nor does requiring certain algebraic properties...besides it couldn't be enforced.

@cass: Seriously, your suggestion would require an extra 'token' to denote an operator, otherwise:
1  
  a add (b+c)


where 'a' is some user-defined type and 'b' & 'c' are prims AND type-of 'a' has both operator add and method add...which is it? Whereas:

1  
  a add: (b+c)


must be the operator.
Online pjt33
« Reply #74 - Posted 2009-11-23 14:35:21 »

@pjt33: Limiting the set of operators doesn't make sense to me. This ignores non-primative scalar types for instance. Nor does requiring certain algebraic properties...besides it couldn't be enforced.
There needs to be a clean compile-time way to check which operations are supported. I suppose you could have an interface per overridable operator if you want maximum flexibility.

Consistency between compareTo and equals or between equals and hashCode can't be enforced. That doesn't stop consistency being in the contract.
Offline jezek2
« Reply #75 - Posted 2009-11-23 15:20:20 »

I prefer DzzD's approach too Smiley Though as I use official javax.vecmath API I have to have it on different lines... but I'm sorta used to it already. Many things are really just about habit. And operator overloading doesn't match Java's goals such as simplicity. If you prefer these things use different language, eg. Scala or C++ Smiley

Well written pure C++ can be pleasure to use too, unfortunatelly C++ allows so many things so that every programmer uses different subset of the language and different libraries are totally inconsistent between each other.

As for closures... I was quite against them in Java even if they're handy for me... if it'll look much like the FCM it's still very Java-like and simple so I would use that without problem, but I hope not much more radical changes will be made to Java in next (at least) 5 years.
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #76 - Posted 2009-11-25 13:32:12 »

official response from Mark Reinhold's why closures are in java 7

http://blogs.sun.com/mr/entry/closures
Offline ido

Junior Devvie





« Reply #77 - Posted 2009-11-25 18:28:53 »

Isn't this just tacking more fake stuff onto the language that it wasn't designed for in the first place?

How is it 'fake'? 

I assume by fake you mean it's syntactic sugar, and there is nothing wrong with syntactic sugar IMO.

Do you also prefer to define Iterators instead of using the for(Obj o : collection) loop?

-Ido.

Offline OverKill

Junior Devvie




Java games rock!


« Reply #78 - Posted 2009-11-25 20:59:55 »

official response from Mark Reinhold's why closures are in java 7

http://blogs.sun.com/mr/entry/closures
Oh, great...  Roll Eyes

Aw hell, let's just turn this into J++ and make sure no lazy ass programmer need not write a single friggn character to much.
S.o.p I'm even to lazy to wri ...

Just look at the (currently) last entry in the blog what some people want ... with pushovers like this, how long until this is added?

Though maybe someone can explain to me what closures have to do with parallel programming.
I mean it seems like the justification to add them.

Not to mention the lame arse 'ohh I have the best idea and if you do not like it, you still live in the past'.
'Move forward' you only hear from people either trying to hide their past or get something through asap under people's noses (like those mid-night bills).

Seriously, if it is added it will NEVER be taken out again, no matter how much people will complain.
'oh, we cannot remove it now, people have already used it in their code and removing it would break it'
Though I doubt people could complain enough, seeing as the people who wanted to add the feature will be the ones that will have to decide if it stays in or not.
How do you convince a person who is convinced of something that they are wrong?

And if that were not enough, yes, let's open up language design to popular demand.
Yeah, that should REALLY help.

(wow, are we talking Bush politics here or Java?)

Java is going down the drain because they are trying to press in new features to make it look like they are not lagging behind (as has often been a point of critique).
They do not want to add some kind of function class that just might make more sense, but closures.. ah fine, let's also make sure the code is nicely obfuscated while we are at it.

How is 'fake'? 

I assume by fake you mean it's syntactic sugar, and there is nothing wrong with syntactic sugar IMO.

Do you also prefer to define Iterators instead of using the for(Obj o : collection) loop?
-Ido.
I rolled my eyes when I saw the foreach but it was not THAT bad.
And, depending on the situation, I even use it quite often.

But seriously, we are not talking about just a foreach loop (a minor change) but a big friggn feature similar to the generics.
And this should not just be taken lightly.
Offline tom
« Reply #79 - Posted 2009-11-25 22:04:21 »

I'm all for features that can reduce the amount of boilerplate code needed in Java.

I like the simplicity of Java and was skeptical about the changes made to Java 1.5.  But now I use more or less all the features that was added. The enhanced for loop is just fantastic. The engine I'm developing uses a property system that could not have been made without autoboxing. I use generics for some simple things like this:
1  
2  
3  
for (Sound sound : world.getComponents(Sound.class)) {
   sound.stop();
}


So I can't wait to get closures. I'm sure it will make Java a better language.

Offline DzzD
« Reply #80 - Posted 2009-11-25 22:13:12 »

I'm all for features that can reduce the amount of boilerplate code needed in Java.
and I am affraid to have as many new java languages features release than we have last 4 years for the JRE (*), symptomatic of too much eagerness like an irrepressible need to evolve/change even when all is going well.

wow never thought I could be able to write such complex sentences in english Smiley

EDIT: (*) I mean with lots of bugs or missthinked stuff

EDIT2: can you image how Java will get complexe in tens years ? this is the same as old software that have evolved for severals years they just suck, java do what it have to do verywell... maybe just start a new language Java2000!!

Offline zingbat

Senior Devvie




Java games rock!


« Reply #81 - Posted 2009-11-25 22:32:56 »

A compliant ahead-of-time compiler may not perform transforms across compilation-units.

Nothing to do with what i said.

Offline zammbi

JGO Coder


Medals: 4



« Reply #82 - Posted 2009-11-25 22:36:17 »

Maybe one day there will be a Java 2.0 that would be rewritten to fix all the mistakes and get everything right.
Legacy stuff could be included to still work with older code.

Current project - Rename and Sort
Offline tom
« Reply #83 - Posted 2009-11-25 22:51:34 »

I agree. Generics and closures should have been included from day one. I think they were left out because of lack of time. The problem now is to retrofit these features.

Offline ido

Junior Devvie





« Reply #84 - Posted 2009-11-25 22:58:04 »

I rolled my eyes when I saw the foreach but it was not THAT bad.
And, depending on the situation, I even use it quite often.

But seriously, we are not talking about just a foreach loop (a minor change) but a big friggn feature similar to the generics.
And this should not just be taken lightly.

I am not taking it lightly, I am asking Notch what is 'fake' about it- that word just doesn't make any sense to me in this context.

It's more about trying to understand his criticism than to refute it.

-Ido.

Offline OverKill

Junior Devvie




Java games rock!


« Reply #85 - Posted 2009-11-26 08:38:45 »

Maybe one day there will be a Java 2.0 that would be rewritten to fix all the mistakes and get everything right.
Legacy stuff could be included to still work with older code.
Like I wrote, we can call it J++ and no, that name is no coincidence.
Online princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #86 - Posted 2009-11-26 11:01:30 »

If they want to get rid of boilerplate code perhaps they might consider adding some type inferencing in the form of automatic casting. Combined with generics that'd probably see of most of the remaining casts in code, like:
1  
String s = (String) someThing;

would just become
1  
String s = someThing;

and the compiler would simply infer there's a cast in there and barf if the cast was impossible. Just as it does now. I just don't see why I should have to tell it that I want it cast to a String.

Cas Smiley

Offline OverKill

Junior Devvie




Java games rock!


« Reply #87 - Posted 2009-11-26 17:43:14 »

If they want to get rid of boilerplate code perhaps they might consider adding some type inferencing in the form of automatic casting. Combined with generics that'd probably see of most of the remaining casts in code, like:
1  
String s = (String) someThing;

would just become
1  
String s = someThing;

and the compiler would simply infer there's a cast in there and barf if the cast was impossible. Just as it does now. I just don't see why I should have to tell it that I want it cast to a String.

Cas Smiley
Yes!
I mean you can still use the casting but if the destination object is clear, why the need?
Though I might add it if the assignment is away from the declaration, just to show what I am doing.
Offline DzzD
« Reply #88 - Posted 2009-11-26 17:59:12 »

Yes!
I mean you can still use the casting but if the destination object is clear, why the need?
Though I might add it if the assignment is away from the declaration, just to show what I am doing.
euh... Shocked no you are crazy it is necessary ?! imagine how much error it will introduce : like in mathematical, stuff will be cast from double to int/float or even String<=>int ? but also in many other case. casting is IMO necessary to avoid lot of confusion. With auto-casting Java may become as php/javascript very hard to be used in area that requiere high precision/smartness.

and why not making all variable type "var" , but hey ! wait the language you define already exist and its name is JavaScript not Java ! Tongue

EDIT :and when it is absolutly clear there is already no need to cast it like :
1  
2  
float f=3;
double d=f;

works without any warning when the inverse dosen't

Online princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #89 - Posted 2009-11-26 19:34:35 »

A cast is either impossible, or it'll throw a CCE at runtime. Me sticking it in brackets is just a waste of my typing. When I assign something to a variable I'm already asserting that it fits without trouble.

Cas Smiley

Pages: 1 2 [3] 4 5 6
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

toopeicgaming1999 (51 views)
2014-11-26 15:22:04

toopeicgaming1999 (44 views)
2014-11-26 15:20:36

toopeicgaming1999 (8 views)
2014-11-26 15:20:08

SHC (24 views)
2014-11-25 12:00:59

SHC (24 views)
2014-11-25 11:53:45

Norakomi (26 views)
2014-11-25 11:26:43

Gibbo3771 (23 views)
2014-11-24 19:59:16

trollwarrior1 (36 views)
2014-11-22 12:13:56

xFryIx (75 views)
2014-11-13 12:34:49

digdugdiggy (52 views)
2014-11-12 21:11:50
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!