Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
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
  ignore  |  Print  
  Another language feature I'd like  (Read 15030 times)
0 Members and 1 Guest are viewing this topic.
Online princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #30 - Posted 2009-07-04 00:56:37 »

Fiddly then Smiley I'll manage fine without it for now, and wait for 1.4.2 to die a miserable death.

Cas Smiley

Offline pjt33
« Reply #31 - Posted 2009-07-04 13:02:33 »

How does one do that in Eclipse?

Cas Smiley
Eclipse doesn't use javac, so the easiest way is probably to configure Eclipse to compile with an ant script.
Offline mh114

Junior Member





« Reply #32 - Posted 2009-07-04 13:49:03 »

In Eclipse, right-click on the project, select Properties. There is a section called Java Compiler. You can set the compiler compliance level there to say, 1.4. Of course this means you cannot use features newer than 1.4, unlike when using Retroweaver, for example. Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #33 - Posted 2009-07-04 14:53:08 »

In Eclipse, right-click on the project, select Properties. There is a section called Java Compiler. You can set the compiler compliance level there to say, 1.4. Of course this means you cannot use features newer than 1.4, unlike when using Retroweaver, for example. Smiley

I believe that was the entire point of their conversation  Roll Eyes Grin

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

JGO Coder




Where's the Kaboom?


« Reply #34 - Posted 2009-07-06 05:15:09 »

Are there still a significant number of Macs without 1.5?  I doubt it.

Offline lithos

Junior Member


Medals: 1
Projects: 1



« Reply #35 - Posted 2009-07-06 05:55:54 »

I only consider that a tiny bit more readable than going through the loop.   I can't imagine how horrible the code could end up looking inside a class that actually accesses a database, or all the bad habits it could end up teaching people to use.

There are no such things as bugs...  Only happy accidents.
Offline ewjordan

Junior Member





« Reply #36 - Posted 2009-07-06 10:19:55 »

I'm kind of shocked that nobody has come out against the crowd and agreed with you yet, Cas - your example requires far fewer keystrokes, is more understandable, and omits all the crap boilerplate that makes maintaining and extending most Java code a nightmare.  I don't see what's not to like, except that it's different from the way things are done now.

I don't know if everyone really thinks the Java "solutions" aren't that ugly or what, but I've personally felt a lot of pain over similar things in Java (filtering and selection are always a bitch since you have to wrap functions in objects in order to pass them around), and I think this would be a seriously useful improvement to the language.

Quote
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
public abstract class Selector <E> {
public ArrayList<E> select(final List list) {
   ArrayList<E> selectedList = new ArrayList<E>();
   for (int i = 0; i < list.size(); i ++) {
      E object = list.get(i);
      if(isConditionMet(object))
         selectedList.add(object);
   }

   return selectedList;
} //end select

//subclasses must overide this method with whatever code is needed
public abstract boolean isConditionMet(E object);
}


See, that's not too bad.   It's just like a FileFilter.
Nothing at all against that code, it's perfectly fine as far as Java code goes, but "just like a FileFilter" is exactly the problem - there's no way to do it better in Java, and that sucks.

In Scala it's worth implementing convenience functions like "select" (or in Scala's case, filter) because I can write
1  
myList.filter( enemy => enemy.life > 0 )
to get a list of living enemies with zero hassle.  Once I have to write
1  
2  
3  
4  
Selector<Enemy> aliveSelector = new Selector<Enemy>() { 
  public boolean isConditionMet(Enemy e) { return e.life > 0; }
};
List<Enemy> alive = aliveSelector.select(myList);

to do the same thing in Java, the abstraction has lost pretty much 100% of its convenience value, since the unabstracted code:
1  
2  
3  
4  
List<Enemy> alive = new ArrayList<Enemy>();
for (Enemy e:myList) {
  if (e.life>0) alive.add(e);
}

accomplishes the same thing and actually uses less code than the "properly" abstracted version.  The only gain is that if the types of filters you use are very restricted, you can pre-write parameterized classes like LivingEnemySelector, etc., saving you a bit of typing.  But from what I tend to see, filtering operations tend to be one-off deals, so you get very little ROI by writing concrete selector classes instead of just inlining them.

Hopefully Java 7 will include proper closures and add a new chapter to this story...
Online princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #37 - Posted 2009-07-06 11:03:58 »

I think deep down it's the same reasons as Hibernate exists - a deep seated fear that graduate programmers have of SQL, never having properly been taught it in situ with some real world problems to solve it remains enigmatic and scary to most Java programmers. If you've been doing SQL for any reasonable length of time you soon come to appreciate how obvious it is for set-based logical operations like for example that big thread on entity systems recently as an alternative programming paradigm.

Not just that but it'd make the whole entity-relationship mapping thing a piece of piss and Hibernate could be slowly tortured to death, as befits it.

Cas Smiley

Offline ewjordan

Junior Member





« Reply #38 - Posted 2009-07-06 11:37:29 »

I think deep down it's the same reasons as Hibernate exists - a deep seated fear that graduate programmers have of SQL, never having properly been taught it in situ with some real world problems to solve it remains enigmatic and scary to most Java programmers.
There's quite an impedance mismatch between Java and SQL, and more generally between the OO and relational database approaches themselves, so I think that's understandable, however unfortunate.

But this stuff should be bread and butter for any language used in enterprise, and that's Java's main target, so I'm not sure why it hasn't been addressed more seriously before.  The cynic in me thinks that Java's movers and shakers prefer to do as little moving and shaking as possible these days - it's real easy to avoid criticism if you don't do anything at all!  Hence the calls to just use libraries instead of changing the language, which (to be fair) are often quite valid.

This particular issue goes deeper than what libraries can accomplish, though - it requires major ease of use to change the way people approach problems, so as long as it's even minorly inconvenient or ugly to deal with set operations as core logic, people will never do it unless they absolutely have to, and even the they won't like it.  Which really sucks, since many problems are most appropriately dealt with in terms of list and set ops, especially the types of data-centric problems that are becoming more and more prevalent as we end up swamped in more data than we know what to do with.

I yearn for a little more control over syntax in Java...DSLs are wonderfully expressive, and I wish we could create our own without leaving the language, that would actually allow for stuff like this to be in a library.  Not holding my breath, though...
Offline erikd

JGO Ninja


Medals: 15
Projects: 4
Exp: 14 years


Maximumisness


« Reply #39 - Posted 2009-07-06 12:19:44 »

fwiw, I think princec and ewjordan are spot on.
I used to think that LINQ just cluttered the language by solving a problem that can better be solved with a library, until I realized how much flexibility and readability it adds. Princec's example demonstrates quite nicely how such a language change can solve the problem in a much cleaner, flexible and readable way than a library possibly can.

So +1 from me.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #40 - Posted 2009-07-06 12:44:10 »

You go down a dangerous road with that kind of thing though - you either 1) special-case LINQ (or whatever) syntax in which case you end up cluttering the language spec for one very specific feature, or 2) add enough language flexibility so that LINQ (or whatever) can be written as a third party library. With the first you risk bloating your language with constant special-case exceptions which most people don't want, and with the second you end up with the possibility of it being redefined so much you never know what the code you're looking at *actually* does (see: Lisp).

I think the only practical method would be something that defines it's own syntax and used it's own compiler to produce suitable bytecode (much like how Nice is java-compatible syntax with additions). But then you'd loose existing tools/ide support (which would suck!).

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Online princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #41 - Posted 2009-07-06 13:43:45 »

Any such addition would have to have an Eclipse plugin from the off. It'd also be nice to have javac use a syntax plugin thing too. So for any bit of the parsing javac couldn't parse it'd somehow delegate to its sub-parsers and work out what to do to compile a bit of code. That'd be a nice solution to the whole issue. Just drop in a library - but the library this time exists as a javac plugin (and of course, probably a runtime library as well)! How cool would that be? You could enable the use of a particular plugin just with a quick annotation at the method or class level.

Cas Smiley

Offline erikd

JGO Ninja


Medals: 15
Projects: 4
Exp: 14 years


Maximumisness


« Reply #42 - Posted 2009-07-06 13:55:57 »

You go down a dangerous road with that kind of thing though - you either 1) special-case LINQ (or whatever) syntax in which case you end up cluttering the language spec for one very specific feature, or 2) add enough language flexibility so that LINQ (or whatever) can be written as a third party library. With the first you risk bloating your language with constant special-case exceptions which most people don't want, and with the second you end up with the possibility of it being redefined so much you never know what the code you're looking at *actually* does (see: Lisp).

I think the only practical method would be something that defines it's own syntax and used it's own compiler to produce suitable bytecode (much like how Nice is java-compatible syntax with additions). But then you'd loose existing tools/ide support (which would suck!).

What do you mean by "one very specific feature" and could you give an example of a "special-case exception which most people don't want"?
I'd say querying data (from collections in this case) is such a generic use case, that including better support for it in the language makes perfect sense.

I'd be more wary of your second suggestion because to me that seems to change the nature of java in quite a drastic way.

Quote
It'd also be nice to have javac use a syntax plugin thing too.
OTOH, it could potentially turn the java syntax into a horrid syntax-ghetto.

Online princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #43 - Posted 2009-07-06 13:59:01 »

It already is a bit of a muddle to be honest what with generics and various new features coming in Java7. There'd be absolutely no harm in having optional syntax plugins for javac as it would essentially silence both camps at a stroke - those who want Java to stay like it is don't need to use any plugins, and those who want to modify it for domain specific purposes can just use a nice cross platform jar file. And those who just want to use bytecode thus produced without being scared by the syntax are free to do so as the bytecode is still bytecode and only requires a runtime library as before. What's not to like?

Cas Smiley

Online Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #44 - Posted 2009-07-06 14:42:05 »

Most of our hassles would be solved by allowing multi-line Strings in Java sourcecode:


String query = "

select
   a
from
   b
where
   c = "+localVariable+"

";


Then you could easily build your queries, and pass them into an API, that does the dirty stuff for you, like parsing. Sure, it would lack auto-completion and compile-time checks, but it would be useful for so many things... Creating multi-line strings with StringBuilders is so 1999.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline pjt33
« Reply #45 - Posted 2009-07-06 14:59:59 »

I used to write Java in a fairly functional style, but I think mixing three paradigms in one language falls into the same trap as C++: you end up with most new to intermediate programmers knowing a subset of the language, but they don't all know the same subset and so maintenance is a PITA.

There are already multiple compilers from functional languages to bytecode - see Scala, LambdaVM, etc. I would see it as more logical to use one of these, possibly alongside pure Java for the rendering, than to bung them together into one language.
Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #46 - Posted 2009-07-06 15:07:13 »

What do you mean by "one very specific feature" and could you give an example of a "special-case exception which most people don't want"?
Well personally I don't particularly like the idea of LINQ being embedded at a language level - it's not something I'd use much and it introduces a lot of new syntax. I *like* the fact that the java syntax is clean and minimal (er, less so with 1.5). There's a feeling of "slippery slope" where today it's collection querying, and the next it's built in sql (because "most people" use sql), then explicit support for financial transactions, and account balancing and it just decends into me yelling "GET THE HELL OUT OF MY LANGUAGE". Shocked

I imagine that it'd get a similar reaction from the "enterprisey" developers if I suggested adding in explicit support for n-dimensional geometry. Being able to do intersections, unions and find contact points between various 2d and 3d geometric shapes would be great with custom language syntax, particularly for games. But I'd never want to force that upon *everyone* using a the language.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline erikd

JGO Ninja


Medals: 15
Projects: 4
Exp: 14 years


Maximumisness


« Reply #47 - Posted 2009-07-06 15:39:25 »

It already is a bit of a muddle to be honest what with generics and various new features coming in Java7. There'd be absolutely no harm in having optional syntax plugins for javac as it would essentially silence both camps at a stroke - those who want Java to stay like it is don't need to use any plugins, and those who want to modify it for domain specific purposes can just use a nice cross platform jar file. And those who just want to use bytecode thus produced without being scared by the syntax are free to do so as the bytecode is still bytecode and only requires a runtime library as before. What's not to like?

I like being able to easily read any java code. That'll be out of the window.
And I like that Eclipse can handle any java code (also the code of 3rd party libs that I download so that I can simply control-click to its source to see how stuff works under the hood). That'll be out of the window too.

Although certainly an intriguing idea, it's not without it's potential problems that deserve some serious consideration imho.

Quote
Well personally I don't particularly like the idea of LINQ being embedded at a language level - it's not something I'd use much and it introduces a lot of new syntax. I *like* the fact that the java syntax is clean and minimal (er, less so with 1.5). There's a feeling of "slippery slope" where today it's collection querying, and the next it's built in sql (because "most people" use sql), then explicit support for financial transactions, and account balancing and it just decends into me yelling "GET THE HELL OUT OF MY LANGUAGE".

Most things can be cleanly solved using libraries, but the things LINQ addresses can usually only be solved with libraries in a somewhat spotty way.
I share your stance towards language changes in general, but I think LINQ solves such common problems that it's at least worth considering.

Quote
Most of our hassles would be solved by allowing multi-line Strings in Java sourcecode:
I think that solves a different hassle, though?

Offline Mr_Light

Senior Member




shiny.


« Reply #48 - Posted 2009-07-06 16:05:05 »

your example requires far fewer keystrokes
if we used typing writing machines I'd might care, instead I use a ide. Moreover it would take me more keystrokes to do the proposed then the 'normal' one.

is more understandable
if you say so.

and omits all the crap boilerplate
And introduces new additional crap.
that makes maintaining and extending most Java code a nightmare.
errr?
I don't know if everyone really thinks the Java "solutions" aren't that ugly or what
Here you go: they aren't

Nothing at all against that code, it's perfectly fine as far as Java code goes, but "just like a FileFilter" is exactly the problem - there's no way to do it better in Java, and that sucks.
There are plenty - 'JIT' it in other words don't start Select until you need the next element. Select on insert in other words the original collection backs the selection etc. etc.

SQL doesn't support all of that cause data is in your database and not at your fingertips. it's cheaper to do it then and there always, because going over the wire is costly.

There is plenty of other stuff where it doesn't work or would cause it to be not alike SQL hell and that is even in the world I can imagine - not even the harsh world out there filled with creative 'abusers'.

In Scala it's worth implementing convenience functions like "select" (or in Scala's case, filter) because I can write
1  
myList.filter( enemy => enemy.life > 0 )
to get a list of living enemies with zero hassle.
With CICE it would be
1  
collection.select(Where(Enemy enemy) { return enemy.life > 0 });
But wait if your saying it's zero hassle and you favor closures and you want 'this' where the hell would java end up then. I don't know but having a zillion things to solve a problem means your maintainers need to understand all these zillion ways. Have fun extending and maintaining your code now.

to do the same thing in Java, the abstraction has lost pretty much 100% of its convenience value
Hmm I must have been doing this wrong all this time. I always abstracted stuff to reduce complexity or as the bootstrap said's: "remove the unnecessary so that the necessary may speak"

Quote
Hopefully Java 7 will include proper closures and add a new chapter to this story...
See above. That problem is also why BGGA and others don't seem to hit home you don't need overlap and that reason is why coping stuff directly from some other language or system doesn't usually work.

I yearn for a little more control over syntax in Java...DSLs are wonderfully expressive, and I wish we could create our own without leaving the language, that would actually allow for stuff like this to be in a library.  Not holding my breath, though...
You confuse me; isn't the advantage of a DSL that it's specific, powerful and focused wouldn't allowing ppl to use 'everything' kill the advantages of a DSL? Perhaps I'm misinterpreting "without leaving the language"?

//edit wait or did you mean the ability to inline a other language ala assembly with c?


Sure, it would lack auto-completion and compile-time checks, but it
I simply love how you silently step over that  Kiss

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.
Online princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #49 - Posted 2009-07-06 16:34:17 »

You language ****s never change! Which is why Java's stuck in the mid-90s still, where it started. I'm fed up of how much boilerplate crap I have to do to get simple things done, and I'd love a way forward to add to Java that had sod all effect on anyone who didn't care. So a plugin architecture for javac would be brilliant, because Orangytang wouldn't have to care about maintaining Java code - because it won't be Java code, it'll be base Java + SQL-over-collections-plugin code, and if that becomes some sort of standard plugin, then he'll learn it.

Cas Smiley

Offline Mr_Light

Senior Member




shiny.


« Reply #50 - Posted 2009-07-06 16:39:57 »

Hey I wasn't finished... Tongue

@Cas I liked that train of though esp with DSL like stuff but i'd just limit it to syntax sugar DSL <- 'transcode' -> Java -> Bytecode
now the issue is that the Java code might look odd as it might be generated so you would need to make the DSL java like and only do simple stuff. The idea is that normal ppl can served up the normal java code but the ppl who have the plugin installed get served up the one with sugar.

Normal ppl see:
1  
2  
3  
4  
5  
6  
7  
@Sugarise(BigNumber)
void foo() {
 BigInteger propertyX = BigInteger.valueOf(10);
 BigInteger propertyY = BigInteger.valueOf(10);
 propertyX = propertyX.add(propertyY);
 propertyX = propertyX.mulply(10);
}


Plugin powered ppl would see:
1  
2  
3  
4  
5  
6  
7  
@Sugarise(BigNumber)
void foo() {
 BigInteger propertyX = 10;
 BigInteger propertyY = 10;
 propertyX += propertyY;
 propertyX = propertyX * 10;
}

Was thinking about this with the whole discussion about memory-mapped-objects or 'memory-based networking'(as opposed of IP)
The network is the computer the computer is a network  persecutioncomplex
Where ppl where also concerned about syntax.

//edit

Quote
You language ****s never change! Which is why Java's stuck in the mid-90s still, where it started. I'm fed up of how much boilerplate crap I have to do to get simple things done, and I'd love a way forward to add to Java that had sod all effect on anyone who didn't care.
You have a problem with handling collections other had problems with keeping their libraries type-safe. Err complaining about generics and saying this isn't that a typical case of having your cake and eat it?

//edit2
btw if you just make a plugin architecture for your ide you don't need to change a thing about java and you can do your stuff now. That and precompilers aren't new are they? if you wanted to do it from the commandline. Release it and make it some "sort of standard plugin, then hewe'll learn it."

What's stopping you?

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.
Online Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #51 - Posted 2009-07-06 18:14:04 »

We really need the IDEs these days! Pre-processors are not supported...

The only way not to b0rk your IDE, is to put the 'new code' in comments...


List items = ...;
List filtered = Filter.filter(
/*
  select
     a
  from
     b
  where
     c = 'd'
*/
);


And then your post-processor does something really fancy persecutioncomplex using the CodeAttribute in Java bytecode.

You can't really do this with annotations, as you lack the 'free style typing' that you really need in these DSLs.

Still no compile-time checks and autocompletion, though. Lips Sealed

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

Junior Member





« Reply #52 - Posted 2009-07-06 18:28:03 »

I think deep down it's the same reasons as Hibernate exists - a deep seated fear that graduate programmers have of SQL, never having properly been taught it in situ with some real world problems to solve it remains enigmatic and scary to most Java programmers. If you've been doing SQL for any reasonable length of time you soon come to appreciate how obvious it is for set-based logical operations like for example that big thread on entity systems recently as an alternative programming paradigm.

Not just that but it'd make the whole entity-relationship mapping thing a piece of piss and Hibernate could be slowly tortured to death, as befits it.

You seem to have a lot of opinions here based on nothing, but this statement is so ridiculous I don't even know what to say. Do you really think the point of Hibernate is to hide SQL from noobs?

As I said before: if you really need another language, there are several alternatives available for the jvm. Have you tried any of them?
Online princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #53 - Posted 2009-07-06 18:43:40 »

Based on very nearly 30 years writing code.

Hibernate is an incredibly complicated and fiddly library that makes an easy task into a pretty complicated one. Largely it seems to revolve around a deep suspicion of simply writing SQL. The other thing it tries to hide is the fact that JDBC is a fiddly way of working with databases compared to say, using SQL directly in the language. Anybody here ever used Powerbuilder? We've just gone 2 steps backwards since Powerbuilder as far as database integration is concerned.

Haven't yet found a viable alternative to using Java. I was thinking of a compatible way forward that would solve the issues I've got but without breaking anything or upsetting anyone.

Cas Smiley

Offline ewjordan

Junior Member





« Reply #54 - Posted 2009-07-06 20:42:53 »

Hmm I must have been doing this wrong all this time. I always abstracted stuff to reduce complexity or as the bootstrap said's: "remove the unnecessary so that the necessary may speak"
There's a lot else to respond to, but this cuts to the heart of the issue - I don't think Java's current state effectively enables the removal of the unnecessary.  When I look at the pure Java examples that do what Cas wants, my eyes are attracted to everything but the "live" bits of code in there, which to me means they fail at the mission.  Screen space is dominated by boilerplate that doesn't vary from use to use, and the tiny bit of logic that does vary from filtration to filtration is all but obscured.  This is true in most real life Java code that I see, in amounts usually proportional to how complex the overall system being designed is.

That's why characters typed is a useful metric even in the face of fancy IDEs that take care of the typing for you - it's not that you actually have to type all that stuff, it's that you have to parse it away when you glance over the code in order to figure out what the real logic is, and as projects grow, development time is dominated by code readability.

IMO, it comes down to this: a filter/map/reduce/fold should always be a one-liner, even if the criteria is only used once, and it's just not possible to achieve that in Java.  I understand that the ability to do this type of thing means some people will abuse it, but that's what code reviews and standards are for.  Reflection can be abused quite readily, but most people would be fired long before they could manage any real damage to a codebase by using it.

Hell, half the time when people abuse reflection it's just to do things that would be trivial if they had closures anyways...who hasn't seen the dreaded reflection-simulated-function-pointer anti-pattern showing up here and there in live code?

Haven't yet found a viable alternative to using Java. I was thinking of a compatible way forward that would solve the issues I've got but without breaking anything or upsetting anyone.
I'd definitely vote for some sort of reasonable compiler plugin system, particularly one that didn't involve an external build step (I'm very aware of all the stuff you can do with annotations and bytecode manipulation now, and it's all a real hassle to use).  The nice thing there would be that we'd all have access to the power, but companies or teams that feared the mess that could be made if their worst programmers had access to it could just forbid the specific compiler plugins at the IT level, which is a lot easier than enforcing coding standards.

Scala has almost exactly what you're talking about, Cas, and it's not perfect or anything (difficult to write plugins), but it's a lot easier to use a plugin than it is to integrate a bytecode processor into a Java build (once it's set up once, it can be used by default whenever necessary): http://www.scala-lang.org/node/140 (...I offer that link with the full acknowledgment that the syntax in that compiler plugin highlights one of the most troublesome aspects of Scala, namely the prevalent operator abuse; luckily that is supported in most IDEs, so you can command+click on <:< to figure out wtf it does...)

Re: IDE integration, the ideal solution there would have been to give the IDE the hooks it needs into the language syntax as part of the plug-in interface.  Generally speaking I'd love if languages started to treat IDE integration as a core concern of the language itself rather than a cosmetic step on top, it would very seriously increase the usability of most languages - my language design thoughts have lately centered on this issue almost above all else, as I think it's quite the failure of most newer languages.  IDE issues are the biggest problem with Scala at the moment, otherwise I'd be pushing it a hell of a lot harder than I am already!
Offline Mr_Light

Senior Member




shiny.


« Reply #55 - Posted 2009-07-07 01:09:51 »

...
You can't really do this with annotations, as you lack the 'free style typing' that you really need in these DSLs.
...

You miss the point where it doesn't need to be a java sourcefile. The thing the plugin shows is simply a different view of your java source ala code folding or uml round tripping the compiler is only fed legal java code. The annotation is there to help the plugin and to allow programmers to differentiate between real/plain java code and this 'view'.

When I look at the pure Java examples that do what Cas wants, my eyes are attracted to everything but the "live" bits of code in there
Cas still lives in 1.4 given an advanced for loop, somehow I can't imaging that that particular example isn't that bad. Hell it all depends on if you care how the select is implemented.

thing means some people will abuse it, but that's...
Perhaps I used the wrong wording: if anyone makes anything there will be other ppl who can do new and exciting things with it. Or; even I can imagine plenty of situations where you'd have overlap or where it becomes awkward let alone all the combinations I can't imagine...

Quote
(I'm very aware of all the stuff you can do with annotations and bytecode manipulation now, and it's all a real hassle to use).
What hassle pricisely?

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 ewjordan

Junior Member





« Reply #56 - Posted 2009-07-07 09:57:44 »

What hassle pricisely?
(re: bytecode post-processing)
Mainly that it's a separate build step, which can lead to some pain if you have to deal with a whole bunch of build files inside a large project.  A very minor inconvenience, to be sure, and nothing that takes more than a little effort to get through, but the process of language improvement is largely about spotting minor inconveniences and removing them. (similar to the boilerplate issue)

Further, bytecode processing is a little weak since it has to operate at fairly restricted locations during the compile cycle (pretty much either before or after the source->bytecode translation).  Scala's compiler plugin architecture is a lot more flexible, allowing plugins to punch through and insert themselves at any of the various compilation/optimization phases, and even create their own hooks for other plugins to latch on to, which provides a lot of power to the plugin writers.
Online Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #57 - Posted 2009-07-07 10:08:09 »

Quote
You can't really do this with annotations, as you lack the 'free style typing' that you really need in these DSLs.
You miss the point where it doesn't need to be a java sourcefile. The thing the plugin shows is simply a different view of your java source ala code folding or uml round tripping the compiler is only fed legal java code. The annotation is there to help the plugin and to allow programmers to differentiate between real/plain java code and this 'view'.

Yeah, right. Changing the view of the source, while the real files are different... Suddenly you find yourself only being able to program in a specific IDE. You can't copy and paste code around anymore. Your sourcecode repository will choke on it. It's simply a really poor solution, if that... it's a whole can of worms.

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

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #58 - Posted 2009-07-07 11:10:21 »

Related, has anyone seen the list of proposed additions in Java7? Null safe handling looks like a practical piece of syntaxtic sugar (through the awesomely named "elvis operator"), and annotations on java types looks like giving us the handy-dandy @NotNull that's been kicking around in Nice for ages.

In fact that's a pretty big list - does anyone know of similar ones for java5 and 6 for comparison? (and I'm wondering if I missed anything cool that got drowned out in all the generics and annotations hype).

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Online princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #59 - Posted 2009-07-07 13:27:23 »

I did see that list - although I did also read a very compelling white paper on how the @NotNull annotation should actually be @Null, as in the vast majority of cases people do not want null values allowed. Intuititively @NotNull is what you'd go for but practically you really want @Null.


Cas Smiley

Pages: 1 [2] 3 4 5
  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.

xsi3rr4x (53 views)
2014-04-15 18:08:23

BurntPizza (51 views)
2014-04-15 03:46:01

UprightPath (65 views)
2014-04-14 17:39:50

UprightPath (48 views)
2014-04-14 17:35:47

Porlus (65 views)
2014-04-14 15:48:38

tom_mai78101 (89 views)
2014-04-10 04:04:31

BurntPizza (149 views)
2014-04-08 23:06:04

tom_mai78101 (245 views)
2014-04-05 13:34:39

trollwarrior1 (203 views)
2014-04-04 12:06:45

CJLetsGame (210 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!