Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 4 5 [6]
  ignore  |  Print  
  Java 7 to get Closures!  (Read 21891 times)
0 Members and 1 Guest are viewing this topic.
Offline HappyCat

Junior Newbie





« Reply #150 - Posted 2009-12-17 13:13:29 »

Cas - you're mad    Grin

You wouldn't be able to make any distinction between the "interface" (which won't change much) and the "workings" (which might change drastically with every release).

Might not matter a jot within your own code, but would make library writing (or even just working in a team) almost impossible, for both the library user ("where's method X gone?") and the library writer ("I need to change that apparently unimportant method prototype, but what if people are using it?").

Offline CommanderKeith
« Reply #151 - Posted 2009-12-17 13:25:24 »

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


And it's most annoying that the default accessibility is package-private. It should be public or at least protected.

Interestingly, I read somewhere that one of two things that James Gosling would have changed about java is that he would abolish class to sub-class inheritance and have interfaces only. (The other thing he wished he could do was ditch AWT)

Offline princec

JGO Kernel


Medals: 364
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #152 - Posted 2009-12-17 13:48:50 »

Aye, see, I've already got a mechanism to distinguish the workings from the interface, and they're called... interfaces Smiley
Turns out AWT is also not so hard to ditch Wink

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #153 - Posted 2009-12-17 15:32:49 »

Interestingly, I read somewhere that one of two things that James Gosling would have changed about java is that he would abolish class to sub-class inheritance and have interfaces only.

Ouch. Seems like a lot of people want SmallTalk with a easier syntax. No wait, SmallTalk has closures...dang!
Offline HappyCat

Junior Newbie





« Reply #154 - Posted 2009-12-18 11:45:47 »

Aye, see, I've already got a mechanism to distinguish the workings from the interface, and they're called... interfaces Smiley
Fair enough - hadn't thought of it that way    Smiley

Offline i30817

Junior Member





« Reply #155 - Posted 2009-12-18 15:53:14 »

Myself, i think interfaces were a mistake.

The real solution is abstract classes ... err... i mean traits.

Predictably there a now a lot of f**kwits on the mailing list fighting against extension methods, without which, lambdas are really f**king useless for the std api.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #156 - Posted 2009-12-24 03:16:16 »

Aye, see, I've already got a mechanism to distinguish the workings from the interface, and they're called... interfaces Smiley
Turns out AWT is also not so hard to ditch Wink

Cas Smiley

How about everything is protected by default and ONLY the methods that implement an interface are public.  No other methods are allowed to be public.  So if you want to add a public method you have to extend or add an interface that your class implements.

I personally thing protected access is strange the way Java did it.  Allowing any class in the same package to access protected fields seems lame.  There is no way to have fields accessible only to the class and other classes that subclass it *without* allowing access to all classes in the same package.

Offline Don Kiddick

Junior Member





« Reply #157 - Posted 2009-12-24 14:43:05 »

My personal take on this, is that the mulitprocessor revolution is coming, or has come. Unless we find some other solution, machines many many processors will be the norm. 2 is the norm now, extrapolating with Moore's law we hit > 200 processors before 2020.

*If* this does happen, our current programming methods with regards to concurrency will not scale. A solution will be found and accepted to this. Currently it seems to be looking like the adaption of ideas from functional programming although there are other ideas abound such as transactional memory. Whatever it is, it will take the headache out of multithreaded programming, either by making it difficult to do unsound things or providing lots of scaffolding to make it easy to do the write thing.

Where would this leave Java? Well there is still going to be huge investment in java lying about. As we've seen with COBOL, it's not going away anytime soon, even if new software will rarely choose it. I see the addition of closures as enhancing the ability of these programs to harness the power of multiprocessing, maybe in just focused performance critical sections. This would allow these programs to live and breathe a lot longer.

I totally understand the problems of bolting on features to the language. Generics are a case in point - I think we can all appreciate the good and the bad of them.

So, there's no easy answer. I think for me, maybe it's too early. Servers with massive numbers of processors are not yet the norm and it even remains to be seen whether they will be. Maybe we will work out another solution to the problem. Maybe it should be java 8?

Happy Christmas,
D.
Offline Roquen
« Reply #158 - Posted 2009-12-27 11:59:51 »

Transaction memory attacks a completely different problem: communication between threads, processes, etc. and is a logical entension of load-link/store-conditional operations.

IHMO, there is no reasonable single way to address all types of concurrent computation: threads, OpenCL/CUDA/Shaders, continuations, and a proper closure all attack different needs.
Offline Mordan

Junior Member





« Reply #159 - Posted 2010-09-25 09:48:52 »

I agree with the simplicity argument but Java needs closures/lambda expressions.

Writing programs would be more readable and elegant. For those who don't really understand. A Method is an Object without the overhead. Defining a class for all your functions is inefficient. Plus anonymes classes are ugly and not byte code efficient.

I have implemented my own little lambda (100+ functions) framework for J2ME because of the class size overhead is relatively huge.
Pages: 1 ... 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.

TehJavaDev (12 views)
2014-08-28 18:26:30

CopyableCougar4 (24 views)
2014-08-22 19:31:30

atombrot (37 views)
2014-08-19 09:29:53

Tekkerue (30 views)
2014-08-16 06:45:27

Tekkerue (29 views)
2014-08-16 06:22:17

Tekkerue (18 views)
2014-08-16 06:20:21

Tekkerue (27 views)
2014-08-16 06:12:11

Rayexar (65 views)
2014-08-11 02:49:23

BurntPizza (41 views)
2014-08-09 21:09:32

BurntPizza (33 views)
2014-08-08 02:01:56
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59: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!