Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (108)
games submitted by our members
Games in WIP (536)
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
  ignore  |  Print  
  Java 7 to get Closures!  (Read 21704 times)
0 Members and 1 Guest are viewing this topic.
Offline pjt33
« Reply #120 - Posted 2009-12-02 20:27:39 »

The less code there is for the maintainer to figure out the less chance he or she has of getting it wrong.
So why do the most compact languages tend to be write-once read-never?
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #121 - Posted 2009-12-02 20:32:40 »

Mostly because they achieve compactness by replacing words with overloaded ascii symbols Smiley

Cas Smiley

Offline i30817

Junior Member





« Reply #122 - Posted 2009-12-02 22:10:50 »

As long as the std lib programmers don't have the temptation to add a overloading for
+= to mean reduce or some stupid thing like that, its all good.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #123 - Posted 2009-12-02 23:01:32 »

I don't want to give a reason - that's the work of machines to figure it out. If it's impossible I'd like to be told, but as long as it's legal to cast, I don't see why I should have to go to the effort and clutter of stating it - it's totally superfluous to the meaning of the code. String s = foo; means I think foo is a String and assign it to s; so does String s = (String) foo; - but one is shorter and clearer.

Cas Smiley

Are you limiting this short-hand to only be applicable when assigning at declaration?
Do you also think that narrowing casts on primitive types should be implicit?

I can see some logic to what you are saying, and implicit widening casts for primitive types does set some form of precedent.

However, I think Java has got it right this time.
An implicit operation that can have an adverse effect (truncate values, increase inaccuracy, or throw Exceptions) is not clear or easy to spot.

I'd much rather be tracking down a
1  
ClassCastException: Foo cannot be cast to Bah
when the code looks like:

1  
a = (Bah)b;

rather than:
1  
a = b;


Also, forcing the programmer to explicitly declare the cast makes them consider (if only for a second); "will casting 'b' to Bah be true in all cases".

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #124 - Posted 2009-12-02 23:13:30 »

An implicit operation that can have an adverse effect (truncate values, increase inaccuracy, or throw Exceptions) is not clear or easy to spot.

You mean like autoboxing? Wink

Play Minecraft!
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #125 - Posted 2009-12-02 23:27:19 »

Except this isn't a conversion. I completely agree that this should not be applied to primitives. I also think that forcing programmers to think is not at all what casting does. It forces us to type, not to think. I don't think about it, I just do it. And it annoys me.

Cas Smiley

Offline pjt33
« Reply #126 - Posted 2009-12-03 00:19:38 »

You mean like autoboxing? Wink
I've already said that autoboxing has caused me problems in the past.

I also think that forcing programmers to think is not at all what casting does. It forces us to type, not to think. I don't think about it, I just do it. And it annoys me.
As far as I'm concerned it forces you to document that the narrowing is intentional and not a case of forgetting what type the RHS has. It also provides compile-time protection against a slip of the auto-complete.
Offline Spasi
« Reply #127 - Posted 2009-12-03 00:44:20 »

I'd like to reinforce my previous point about how any language change shouldn't be evaluated in a "plain-text" environment, but only through the use of a powerful IDE:

- Java 7 is adding Improved Type Inference for Generic Instance Creation. The beta of (now open source) IntelliJ IDEA 9 allows you to do that, even on Java 5. It looks like this or this. If you mouse over such statements, you get a nice tooltip showing the "plain-text" code.

- How about closure-like code folding for anonymous inner methods? IDEA 9 can do that too and it looks like this.

- Same techniques can be utilized in many other coding constructs to ease our programming life, how about i18n inlining? I can imagine tools in future IDEs that would allow us to build our own boilerplate-code-hiding.

About casts and type inference. I guess the cast hiding that Cas wants could be implemented just like the above examples, without any language changes. Furthermore, clever IDEs can help us with identifying potential problems and I'll give IDEA's handling of auto-boxing/unboxing as an example. It has an inspection that simply detects auto-boxing/unboxing usages in your code. You can configure that inspection anyway you like, for example you can set it to be an error. So, next time you unwillingly use autoboxing in your code, it will immediately highlight that usage and you'd be notified the exact moment you typed it. Or it could be a simple warning. Or you can hide it and later run the inspection on your whole project and fix any potential issues. The same thing could be done with cast hiding.

Tbh, I wouldn't be surprised if you could write a plug-in for IDEA that implements an operator-overloading (or the operator methods that Cas prefers) code transformation, right now. Wink
Offline i30817

Junior Member





« Reply #128 - Posted 2009-12-03 02:02:23 »

Fragmentation is not a good thing. for a feature to gain adherents for the libraries to be built it has to reach every where the library is going to be used.
Offline Spasi
« Reply #129 - Posted 2009-12-03 12:01:22 »

Of course, but the features I described above aren't changing anything to the underlying code, so no changes are necessary to any libraries or to code from users that aren't using IDEA.

My point was that if you need something like that now, there's an option available. My other point was that code-simplifying techniques aren't necessarily as "evil" as some of the above posters make them sound to be. Java will never become C++.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #130 - Posted 2009-12-03 12:39:42 »

C++ does not appear to have any code simplification features at all Smiley

Cas Smiley

Offline Spasi
« Reply #131 - Posted 2009-12-03 13:05:03 »

I was thinking feature bloat in general, not strictly code simplification. Anyway, C++ does have code "simplification" stuff: operator overloading, macros, typedefs... all reducing the amount of typing you have to do, while killing your brain cells at the same time.
Offline ewjordan

Junior Member





« Reply #132 - Posted 2009-12-04 13:00:21 »

(I'm assuming that quaternions would be added to your list of basics).

Hehe, we can dream, can't we?  But I'm a realist - I think there's maybe a 5% shot of ever seeing vector or complex primitives, so I doubt quaternions are on the table, let alone octonions or any of the other fun stuff that a math dork might want...

Quote from: Roquen
3) Clifford came along: grokked Quaternions, grokked Exterior algebra.  Figure how to merge them, fills in the missing parts and works for topologies other than Euclidiean.  Then he died young.  He wasn't a rock star, so he was promptly forgotten...oh well.
Hey, don't be so hard on Clifford: we still have Clifford algebras, so he made his mark. Smiley  Then again, only people working on relativistic quantum mechanics ever touch the things, so maybe you're right...

Pretty good summary, by the way.  One thing I'd add is that David Hestenes really tried to push "geometric algebra", which is pretty much what you get when you try to handle all types of N-forms as pieces of the same object.  More accurately, it's a Clifford algebra equipped with a special product that does "nice" things.  I did a bit with these things when I was doing gravity stuff in college, and I remember thinking that they really did make a lot of vector analysis easier because you get a lot of extra information "for free"; might be worth reading up on if you like this stuff.

Sorry to drag this OT...
Offline zingbat

Senior Member




Java games rock!


« Reply #133 - Posted 2009-12-05 21:54:40 »

You have JOCL, which i believe let's you compile code that will take advantage of GPUs to do vector math, but i would rather see this abstracted directly into the language. The problem i see is that Java is a sort of C language for the Java VM and network applications which are meant to run in all kinds of targets like mobile phones or even a refrigerator with a JVM connected to the internet.
Offline OverKill

Junior Member




Java games rock!


« Reply #134 - Posted 2009-12-07 14:10:55 »

I'd like to reinforce my previous point about how any language change shouldn't be evaluated in a "plain-text" environment, but only through the use of a powerful IDE:
Does the spec say this?
This is wrong in so many ways I cannot even begin to list.

I was thinking feature bloat in general, not strictly code simplification. Anyway, C++ does have code "simplification" stuff: operator overloading, macros, typedefs... all reducing the amount of typing you have to do, while killing your brain cells at the same time.
But that was not what Cas was talking about, but more like the foreach loop.

Come on, I have no problems with simplifications but what next, press a and the code should write itself?
Stuff should be added because it makes sense, not to pamper lazy coders.
Online Roquen
« Reply #135 - Posted 2009-12-07 14:40:53 »

Stuff should be added because it makes sense, not to pamper lazy coders.

What features discussed here does this refer to?
Offline Mr_Light

Senior Member




shiny.


« Reply #136 - Posted 2009-12-08 06:32:46 »

Good news, but reading from the spec i can't understand if non-local returns are in or not.

they aren't in.

which I'm happy about as they serve no use. FCM style control structures are fine and it demonstrates how you can avoid a bucket load of weirdness. I don't think FCM proposal is the way to go as far as lamba/closures go, I prefer automatic conversion to SAM's and simply leaving method types out completely. If your writing a 'dsl' for using reflection then I'm all for it but for mainstream java it has a very low power-to-weight ratio.

CICE + FCM style control structures + annoyous method and automatic conversion to SAM and other left hand magic is what I want.

so no
1  
#int(String foo, String bar) throws FoobarException likenessCountFunction = #(String foo, String bar) {.....} ;

nonsense

or
1  
2  
target.addSignalListener(Event event => insert multi
line/ mutiply instructions here and it looks horrible)

nonsense

only thing I haven't settled on is IF/how of finalness of variables in a lamba/closure thingy.

As far as stuff that can be added as IDE plugin I'm all for that, where it doesn't get too crazy - and with control structures it does get too crazy. With respect to the 'final variable' bit of the equation changing anything there takes a language change no matter how you slice it.

method(new SAM() {
 samMethod() {
  OuterClass.this.foo();
 }
});
and using automatic conversion :
method(this#foo());
be handled by IDE plugin is alright. - anyways I though we already had a lengthy discussion about IDE's ~ language features.
I wouldn't want primitives to become Objects. That's why they're primitives! They're he tacit admission that somewhere underneath the JVM is a real machine that...
The whole Objects have an identity makes modelling primitives as Objects scewy, though it boils down to the same thing. Having something that allows you to specify that you do not care if you get a primitive or a object could do some good though, say you define methods that take a SAM then with primitives you end up with at least 8 SAM's which is a bit tedious to define every time, the other option is to throw typing out the door which doesn't sound too appealing.

They work fine, they're not too complicated if you don't try to over use them, and the new Java 7 syntax for inferring generic type sigs should make them far less verbose.
Yeah I really don't understand the fuzz with generics they get picked up without a hitch by all the students I come across. Consuming them is never a problem, defining them might impose a bumb or two but in general API design isn't something junior programmers get right anyway.

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.
I don't know where your coming from but a programmers assertion even if it's me doesn't rate the same as a compilers assertion. When a programmer takes stuff in it's own hands I don't mind it showing though using verbosity. Last but certainly not least, I don't think your typing casts all day, so get over it anyway :p

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline OverKill

Junior Member




Java games rock!


« Reply #137 - Posted 2009-12-16 11:29:47 »

So has anyone been able to explain how closures will help with concurrency?

Anyway, I've been looking into Vala a little which also has closures.
Not that I was looking for them, mind you.

Vala does have a nice list of features which are very interesting and worth a look, even if just to get a feel for some of the topics discussed in this thread (operator overloading, closures)

Sample:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
// using Glib; -> not needed, is like java.lang

public class Main
{
  public static int main (string[] args)
  {
    Gtk.init (ref args);

    Gtk.Window window = new Gtk.Window (Gtk.WindowType.TOPLEVEL);
    window.set_default_size (300, 200);
    window.destroy += Gtk.main_quit;

    var box = new Gtk.VBox(true, 5);
    window.add (box);
    box.add (new Gtk.Label ("Hello World!"));
   
    var button = new Gtk.Button.with_label("click me");
    box.add(button);
    button.clicked += ((source) => {
      window.destroy();
    });        

    window.show_all ();
    Gtk.main ();
    return 0;
  }
}


As visible the button.clicked signal can be incremental assigned (  Tongue ) with a method. Now of course you have to know that += is shorthand for connect and -= for disconnect

then you think 'hmm.. so what kind of method signature does the clicked method have?', so you check the docs and see:
1  
public signal void clicked (); 


hmm... strange, this does not match the method signature.
then you read the doc:
Quote
A signal may also have multiple parameters. The signatures of the callback functions have to match the one of the signal, except that you may either leave out as many parameters from the end of the signature as you like or provide the signal source additionally as the first parameter of the callback function. Example:

1  
2  
3  
4  
public class Foo : Object {
    public signal void some_event (int x, int y, double z);
    // ...
}


The following callback signatures now match the signal:

1  
2  
3  
4  
5  
void on_some_event ()
void on_some_event (int x)
void on_some_event (int x, int y)
void on_some_event (int x, int y, double z)
void on_some_event (Foo source, int x, int y, double z)


Why not just state so from the beginning? Is this VB?

A feature is also that you can add multiple handlers for one signal (or I have not yet found out how to limit it). Can be good, can be bad.

One thing to note: in contrast to Java, where one handler can have multiple methods, in Vala it only awaits that one method. (so it seems atm)
Also in Vala, methods as parameters are fine. (something I miss in Java, but have no problems if it is not in the language spec)

As promising as Vala looks (and yes, I'll be doing more work with it) it does seem to have fallen a little prey to the feature creep.
Let's just add it because it's cool... or typing hurts my fingers.
Was connect and disconnect to hard to write out, instead of +=?
Would it have been to hard to write new clicked (source) instead of (source) => (not like it is actually that much less typing)?
Are hidden + injected method arguments good?

Some of these just take away the clarity when reading it IMHO.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #138 - Posted 2009-12-16 12:21:16 »

Yup, looks awful.

Cas Smiley

Offline xinaesthetic

Senior Member


Medals: 1



« Reply #139 - Posted 2009-12-16 12:59:39 »

So has anyone been able to explain how closures will help with concurrency?
I did mention earlier that lazy evaluation leaves more chances for the runtime to come up with an effective strategy for when to execute the code.  For example, on elements of a list in parallel.

Of course it's always possible to contrive a way of doing this with existing mechanisms, but closures seem to make these things more natural and simple.
Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #140 - Posted 2009-12-16 13:40:29 »

If I designed a language, I'd make blocks be function literals, a proper function type with named arguments, and function type inference.

Then you could write this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public class Frame {
    public Function(int x, int y) onMouseClicked = null;
}

// Using default argument names
myFrame.onMouseClicked = {System.out.println("You clicked at "+x+", "+y)};

// OR:

// Renaming the arguments (could just rename the first argument if wanted, but have to rename them in order)
myFrame.onMouseClicked = (Function(int r, int n)){System.out.println("You clicked at "+r+", "+n)};

Function(int i) print = { System.out.println(i) };
for (int i=0; i<10; i++) print(i);


Of course, there are millions of potential problems with this. Wink

But at least it LOOKS CLEAN.

[size=32pt]*HINT, HINT*[/size]

Play Minecraft!
Offline pjt33
« Reply #141 - Posted 2009-12-16 16:04:52 »

If you want clean syntax for functions as first class types then look at languages which were designed from the start to be functional*. SML or Haskell, say.



* But not LISP. Later functional languages were able to learn from it.
Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #142 - Posted 2009-12-16 16:15:24 »

Yes, I agree. My point is kinda that one shouldn't try to force broken implementations into a language. If you want some feature, redesign the language or move on to another one.

Visual Basic was pathetic. Java's working hard on getting there.

The JVM is super good and works really well, but I feel like java as a language is starting to fail.
Either leave it alone, or redesign it. Don't tack things on.

Play Minecraft!
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #143 - Posted 2009-12-16 17:17:03 »

I just want BASIC, with classes and structs Smiley And the total removal of public, protected, and private modifiers! But then, I'm a rebel.

Cas Smiley

Offline pjt33
« Reply #144 - Posted 2009-12-16 21:01:42 »

And the total removal of public, protected, and private modifiers!
persecutioncomplex I suppose there is always the Eiffel model of specifying precisely which classes have visibility of each member...
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #145 - Posted 2009-12-17 01:33:08 »

Nah, I just say - if it can be seen on the client, then it can be decompiled, ergo the source is visible, ergo there is no "hiding". So it may as well all be public. I think the entire concept of encapsulation has just been a huge, massive, mistake, and maybe we're just beginning to figure this out.

The number of times I've been pointlessly thwarted trying to get some feckwitted library to do my bidding but been stuck because some bit of code was protected or private that I wanted to call or override... grr

Cas Smiley

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #146 - Posted 2009-12-17 03:30:34 »

Nah, I just say - if it can be seen on the client, then it can be decompiled, ergo the source is visible, ergo there is no "hiding". So it may as well all be public. I think the entire concept of encapsulation has just been a huge, massive, mistake, and maybe we're just beginning to figure this out.

The number of times I've been pointlessly thwarted trying to get some feckwitted library to do my bidding but been stuck because some bit of code was protected or private that I wanted to call or override... grr

Cas Smiley
It is nice, however, to at least know what is supposed to be private and what isn't. And if you use setter methods instead of directly changing a variable you can have a lot more control when debugging (if something goes wrong with that variable, you can just put a breakpoint in the setter and see who called it).

See my work:
OTC Software
Offline OverKill

Junior Member




Java games rock!


« Reply #147 - Posted 2009-12-17 09:47:01 »

@princec:
I'd have to disagree on that one.
Even with the current implementation, people do not abide to even the simplest systems and regulations.

At work we had a discussion about the way the OSGI framework allows the explicit declaration of public interfaces and that then only those can be used.
Then these are only visible in the IDE.
Now I won't use an entire framework just for one feature for an IDE/other OSGI components that otherwise would have any influence, but it would be a REALLY good feature in Java.
Plus a lot of stuff mentioned in the Practical API Design book.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 749
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #148 - Posted 2009-12-17 09:51:01 »

Nah, I just say - if it can be seen on the client, then it can be decompiled, ergo the source is visible, ergo there is no "hiding". So it may as well all be public. I think the entire concept of encapsulation has just been a huge, massive, mistake, and maybe we're just beginning to figure this out.

The number of times I've been pointlessly thwarted trying to get some feckwitted library to do my bidding but been stuck because some bit of code was protected or private that I wanted to call or override... grr

Cas Smiley

Maybe access to protected/default/private fields/methods would result in a compile time warning (automatically making the actual field/method public in bytecode).

Ok, you can start roundhouse kicking me

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

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #149 - Posted 2009-12-17 10:54:04 »

I'm just erring more and more towards the "scripting" style of coding. Y'know, where the compiler helps figure out what you want to do, rather than stops you from doing it.

Cas Smiley

Pages: 1 ... 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.

CogWheelz (16 views)
2014-07-30 21:08:39

Riven (22 views)
2014-07-29 18:09:19

Riven (14 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (33 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!