Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (120)
games submitted by our members
Games in WIP (577)
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
  ignore  |  Print  
  If you could change Java, the language, what would you change?  (Read 21766 times)
0 Members and 1 Guest are viewing this topic.
Offline Mr_Light

Senior Duke


Medals: 1


shiny.


« Reply #30 - Posted 2007-02-06 19:28:01 »

This has little to do with what princec was saying, but I really don't want to have my crappy little helper methods exposed for use by anyone.  I would like to type less though.

The problem with this is that it could make it marginally harder to tell which methods are public/private/whatever while you're programming, but an IDE could use different-colored text or have some kind of marker or something.

There is another thing that annoys me even more, but it's more a matter of style.  The "normal" way to write a class is to indent every line inside of the class, but that uses up alot of my valuable screen space (which sometimes causes my expressions with long variable names to take up multiple lines).  The only information the first layer of indentation provides you with is that you're not writing package or import statements and so that you can see the not-indented start and end points of .  Presumably, you can tell the difference between those statements and the actual code.

If you want some kind of marker to make the class definitions stand out more without the indentation, just use a comment like the following:

1  
//#####################################################################################


So I take the simple way out and just don't use the first layer of indentation.  But it screws up the way Eclipse indents the code sometimes, and then I have to fix it.

And why have end brackets for classes?  Why not just have something like the following:

use udbble space for indents, and don't raise the cyclomatic complexity beyondsomething stupid.

as for brackets defining your code block, there great and the last one you don't type anyway not in any ide I know ######### don't make any sense.
.. not anywhere I've worked. Who does that!?

yeah!

e.printStackTrace(); -> logger.error(e);

 Grin Wink

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 cylab

JGO Ninja


Medals: 52



« Reply #31 - Posted 2007-02-06 19:40:23 »

e.printStackTrace(); -> logger.error(e);

 Grin Wink

e.printStackTrace(); -> throw new RuntimeException(e.getMessage());
 Roll Eyes Lips Sealed Roll Eyes

Mathias - I Know What [you] Did Last Summer!
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #32 - Posted 2007-02-06 20:21:53 »

Then at least do:

e.printStackTrace(); -> throw new RuntimeException(e);

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

Junior Duke





« Reply #33 - Posted 2007-02-06 23:48:02 »

1. I'd add "NOT NULL" as a modifier to variables, and get the compiler to assert whether something could possibly be null and complain. Why? Because I'm sick of having to assert whether something's null or not when a compiler should be much better at doing the job than me.
I would like this as well. I like the way @NotNull works in IDEA, and I would want the VM to do runtime null/not-null checks automatically. I've heard there is a JSR about adding more annotations (including not null) to the standard Java API, so I'm quite sure that we'll get this sooner or later. The only problem I see, is that having annotations in front of every method parameter makes the code a bit messy.

2. I'd remove checked exceptions. Why? Because they don't actually appear to make it any easier to code correctly. Exceptions always get caught by the VM and are handled correctly anyway.
I oppose. What I would do instead, is improve the way that Java API uses checked exceptions. Checked exceptions should only be thrown, when it is possible to recover from the exception (in other words, it is part of the business logic). In case of faults (such as I/O errors and programming mistakes), only unchecked exceptions should be thrown.

This excellent article explains the correct way of using checked and unchecked exceptions: http://dev2dev.bea.com/pub/a/2006/11/effective-exceptions.html

3. I'd remove the need to make casts where the type can be inferred. Why? Because when it's obvious that you're attempting to make a cast, why should you have to type it?

5. I think I'd make mapped objects a first class language construct Wink
Oh I just remembered one of the most important things I left off the list: operator declarations, which enable you to declare static methods as operators, eg. the much fabled dot operator for Vector3fs:
If anything, I would want to increase the use of access modifiers, but I don't necessarily want to have to type them every time.
I'm against all syntactic sugar, which does not improve the readability of the code. Modern IDEs take care of most of the typing, so verbose code is not any slower to write. When looking at a code, it should right away be clear what the code does, but if things such as operator overloading are used, you can't really know what the code does by just looking at one spot.

Here is an article about the dark side of Java 5 features: http://www.jroller.com/page/vprise?entry=java_5_language_changes_were

The "normal" way to write a class is to indent every line inside of the class, but that uses up alot of my valuable screen space (which sometimes causes my expressions with long variable names to take up multiple lines).
Get a bigger screen. Wink On a wide-screen 24" (1920x1200 resolution) you could have very long lines, and they would still fit on the screen. (Except that it's hard to read long lines, so you better fix your code if you have deep indentations.)

6. I'd add the "const" keyword back into the language, and maybe enforce that at VM level too. Why? Because it's easier than all the of alternatives!
Could you explain what you meant? What I understood, is that it would be possible mark methods with "const", and then if a reference to that class is also marked "const", it would be allowed to call only the "const" methods. This might help to avoid accidental modification of a mutable object. I'm not sure how useful it would be.

Offline cylab

JGO Ninja


Medals: 52



« Reply #34 - Posted 2007-02-07 08:15:19 »

Then at least do:

e.printStackTrace(); -> throw new RuntimeException(e);

It was a joke and discarding the cause was the best part of it Wink actually I consider rethrowing checked exception as runtime exceptions the root of all evil (at least similar)

Mathias - I Know What [you] Did Last Summer!
Offline aldacron

Senior Duke


Medals: 9
Exp: 16 years


Java games rock!


« Reply #35 - Posted 2007-02-07 09:02:51 »

It was a joke and discarding the cause was the best part of it Wink actually I consider rethrowing checked exception as runtime exceptions the root of all evil (at least similar)

When it's a checked exception that you can't recover from, throwing a RuntimeException is a perfectly good solution.
Offline cylab

JGO Ninja


Medals: 52



« Reply #36 - Posted 2007-02-07 10:11:28 »

When it's a checked exception that you can't recover from, throwing a RuntimeException is a perfectly good solution.
Yeah you are right. I was a bit rash with my statement. But at least one should throw a concrete RuntimeException subclass (where possible) with a descriptive message text and a correctly initialized cause.

Mathias - I Know What [you] Did Last Summer!
Offline cylab

JGO Ninja


Medals: 52



« Reply #37 - Posted 2007-02-07 10:24:59 »

I'm against all syntactic sugar, which does not improve the readability of the code. Modern IDEs take care of most of the typing, so verbose code is not any slower to write. When looking at a code, it should right away be clear what the code does, but if things such as operator overloading are used, you can't really know what the code does by just looking at one spot.
IMHO operator overloading would improve code readability by a great margin. Especially when it comes to vector and matrix math the current situation in java is a pain in the a... I also don't see any difference between operator overloading and method overloading. It comes down to the discipline of the coders to not misuse operators. Nobody stops you to overload maybe the hashCode()-method to e.g. return the number of times an object is used - but nobody would do that.

Mathias - I Know What [you] Did Last Summer!
Offline Mr_Light

Senior Duke


Medals: 1


shiny.


« Reply #38 - Posted 2007-02-07 10:57:42 »

there's an actual contract for that in place, it maybe not be harshly enforced but it's there.

open for extension, closed for modification comes to mind

hows every one on http://tech.puredanger.com/2007/01/26/java7-property/

I haven't looked at it closely, I'm still forming my opinion.

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 princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #39 - Posted 2007-02-07 11:04:45 »

I'm not sure why anyone in here is opposed to operator declaration - notice it's not operator overloading as in C++, which involves redefining crazy symbols like * ~ !, but simply declaring methods that are designed to be used as unary or binary operators.

Cas Smiley

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

Senior Duke




Go Go Gadget Arms


« Reply #40 - Posted 2007-02-07 11:13:05 »

How would you specify method overloading priority? Like BODMAS but with methods...

So if you do:

1  
Vec3f vec = vec1 dot vec2 mul 4f;


Which is done first? The vec2 mul4 or the dot?

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #41 - Posted 2007-02-07 11:15:17 »

I dunno, presumably standardise on one convention like left-to-right association or something.

I like the properties proposal. Writing get and set methods is just plain stupid.

Cas Smiley

Offline g666

Junior Duke





« Reply #42 - Posted 2007-02-07 11:18:06 »

maybe im stupid, but cant most of these ideas people have suggested be done inside of an ide, with macros of something, without changing the language?

desperately seeking sanity
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #43 - Posted 2007-02-07 11:24:45 »

maybe im stupid, but cant most of these ideas people have suggested be done inside of an ide, with macros of something, without changing the language?

I suppose the ideas are mostly about code readability and simplifying. Having a smarter IDE doesn't make the code more readable, it might merely just save some typing.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #44 - Posted 2007-02-07 11:49:52 »

I'm not sure why anyone in here is opposed to operator declaration - notice it's not operator overloading as in C++, which involves redefining crazy symbols like * ~ !, but simply declaring methods that are designed to be used as unary or binary operators.

Yes, it's not as bad. And, actually, since I've never programmed in a high-level real-work language that allowed user-created-operators (done it in scripting languages and in odd niche languages, never anything mainstream) I ought to be a lot less reactionary, since it could be a lot easier than I expect.

Sorry for the strong reaction, but I'm partly conditioned by e.g. the reactions to your original structs proposals, where the similarity of what you were suggesting to something else (that was also popular) blinded many people to the specific details of what you were actually saying Smiley. When people want something, they often see what they want to see, not what you're actually saying.

I would like to experiment with operator dec and see how it worked out in practice. In theory, once eclipse has support for it, so that I could mouseover the operator to get a description of it, it *could* be no more disruptive than ADT's are now.

malloc will be first against the wall when the revolution comes...
Offline Jackal von ÖRF

Junior Duke





« Reply #45 - Posted 2007-02-07 12:49:00 »

I'm not sure why anyone in here is opposed to operator declaration - notice it's not operator overloading as in C++, which involves redefining crazy symbols like * ~ !, but simply declaring methods that are designed to be used as unary or binary operators.
Well, that makes more sense. At least then it would not be confused with the basic arithmetic/bit operators.

1  
Vec3f vec = vec1 dot vec2 mul 4f;

The operators would at least require color highlighting in IDEs, or a different syntax. Otherwise it might be possible to mix variables and operators (i.e. is "dot" an object or an operator - maybe "vec1" and "mul" are unary operators, "vec2" is a binary operator, and "dot" and "4f" are variables).

hows every one on http://tech.puredanger.com/2007/01/26/java7-property/

I haven't looked at it closely, I'm still forming my opinion.
I don't like the syntax "foo.property = value", but automatically generated getter and setter methods would be useful. For example, fields could be marked with a @Property annotation (optionally taking parameters: read-only, write-only, property name, visibility, events etc.), and the compiler would generate the code for simple getters and setters. This would keep compatibility with legacy code, would allow customizing the getter/setter implementation without changing the API, and would provide better documentation for properties (for example, the javadoc for getter and setter would be copied from the javadoc of the property field).

Having an object representation for properties would also be handy. However, it might be best to avoid adding new operators such as ->. Maybe this could be done with some new API.

Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #46 - Posted 2007-02-07 13:42:04 »

I am absolutely against adding crazy new meanings for squiggly symbols... one of the reasons AOP makes me shudder is because it looks like gobbledigook.

What I really want, I suppose, is ways of saying things that we do now, but with much less typing, such that it's easier to just glance at something and know that it works in a particular way. If for example the "property" keyword were added, we'd know that accessing a property went through the defined get/set methods if defined. I suppose that means interfaces are going to need to be able to define properties too.

I quite like the idea of being able to embed XML snippets directly in sourcecode (there's an RFE for that for Java 7).

I also like the suggestions of block modifiers, such a simple thing to implement in the compiler:
1  
2  
3  
4  
5  
private property {
int a;
String s;
float foo;
}

Much nicer than
1  
2  
3  
private property int a;
private property String s;
private property float foo;


Cas Smiley

Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #47 - Posted 2007-02-07 15:41:55 »

Hmyea "named operators" are certainly better than overloaded operators. But I don't think that we really need em.

Operator overloading is usually used for stringcat, vector stuff and for trying to make C++ sorta managed.

We already got the + op with strings and we really don't want to emulate a stone age vm. What's left is vector stuff, which could be done with build-in vector classes (with overloaded operators).

弾幕 ☆ @mahonnaiseblog
Offline zingbat

Senior Duke




Java games rock!


« Reply #48 - Posted 2007-02-08 20:31:10 »

The only thing i would like to see expanded was algebra primitives: tuples, points, vectors, matrices, quaternions, complex numbers.  With the usual primitive operations optimized to take advantage of the hardware this could explore the advantages of using a jvm over native code.
Offline zingbat

Senior Duke




Java games rock!


« Reply #49 - Posted 2007-02-08 20:35:33 »

I'm not sure why anyone in here is opposed to operator declaration - notice it's not operator overloading as in C++, which involves redefining crazy symbols like * ~ !, but simply declaring methods that are designed to be used as unary or binary operators.

Cas Smiley

What's the problem with that? It's wrong to deprecate a language to babysit bad programmers.
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #50 - Posted 2007-02-08 22:29:46 »

What's the problem with that? It's wrong to deprecate a language to babysit bad programmers.

Most of us are using Java for the productivity gain.

弾幕 ☆ @mahonnaiseblog
Offline zingbat

Senior Duke




Java games rock!


« Reply #51 - Posted 2007-02-09 00:02:32 »

Most of us are using Java for the productivity gain.

So?
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #52 - Posted 2007-02-09 00:28:09 »

So?

Operator overloading decreases productivity in the long run. Trading some typing work against clarity is a bad trade. Do you really want a language where x+=5 can mean something completely random?

弾幕 ☆ @mahonnaiseblog
Offline zingbat

Senior Duke




Java games rock!


« Reply #53 - Posted 2007-02-09 00:41:38 »

But it can also increase clarity if well used. With my idea of primitive vectors:

vec v1 = (1,1,1);
vec v2 = (0,0,1);
mat  m = ((2,0,0),(0,2,0),(-1,-1,1));

//vector add
v = v1+v2;

//scalar mul
v = v1*k

//dot prouct
v = v1*v2;

//transformation
v = v1*m;

//in place transformation
v *= m;

Compare this to the more verbose version and tell me what is more clear.

Poor programmers will always write bad code one way or another.
Offline nonnus29

Senior Duke




Giving Java a second chance after ludumdare fiasco


« Reply #54 - Posted 2007-02-09 00:56:20 »

Quote
3. I'd remove the need to make casts where the type can be inferred. Why? Because when it's obvious that you're attempting to make a cast, why should you have to type it?

Kim Bruces book "Foundations of OO Languages" despite the name, is actually about types and oop languages.  He says the main obstacle to ML style type inference in OO languages is the incomplete concept of types as classes/data abstractions.  In practice the difficulty in inferring types in current oo languages (ie java) is inheriting classes and overriding methods.  Method selection is static at compile time.  Plus, over riding a method in a subclass can destroy the meaning of the method if it's used in the super class.

Typing and type inference is not trivial.

Quote
Here's another controversial suggestion: ditch public/private/protected modifiers. All they do is make it harder to modify OO code to do what you want it to do. Most of the time, I want to modify someone else's library in some way using extension, and quite often that involves hackery because I want to use that code in a way they just plain didn't realise.

This gets my vote as the number one thing wrong with oop: Encapsulation and inheritance impede code reuse.  Period.  (imho).
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #55 - Posted 2007-02-09 01:13:09 »

But it can also increase clarity if well used. With my idea of primitive vectors:

vec v1 = (1,1,1);
vec v2 = (0,0,1);
mat  m = ((2,0,0),(0,2,0),(-1,-1,1));

//vector add
v = v1+v2;

//scalar mul
v = v1*k

//dot prouct
v = v1*v2;

//transformation
v = v1*m;

//in place transformation
v *= m;

Compare this to the more verbose version and tell me what is more clear.

Poor programmers will always write bad code one way or another.


As I said... build-in vector classes with overridden operators (like it has been done for String) could be nice.

弾幕 ☆ @mahonnaiseblog
Offline Mr_Light

Senior Duke


Medals: 1


shiny.


« Reply #56 - Posted 2007-02-09 09:19:10 »

This gets my vote as the number one thing wrong with oop: Encapsulation and inheritance impede code reuse.  Period.  (imho).
Quote
in a way they just plain didn't realise.

if they didn't realise it, then it wasn't designed for it and thus your breaking contracts sooner then later, which kills maintainability and creates another shit load of problems OO is about objects and methods and what they represent not the instructions contained in it.

the cases that you can sum up that aren't covered by the earlier statement are cases of bad design.

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 princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #57 - Posted 2007-02-09 11:49:57 »

I think that nearly everybody has realised in practise that OOP isn't about objects and encapsulation, it's just another take on trying to write as little code as possible to do the most work, because at the end of the day, that's all we really care about. Why do we think scripting languages have taken off so fast suddenly? Less code for more work. Little imposition about somebody else's ideas on your own ideas.

I mean, it's all very well saying "Yes but we're software engineers! I write libraries for other people to use!" But when that other person is me and I can't bloody override something in your library because it's private and hence can't make the bit of code working that I'm working on right now it just annoys the hell out of me!!

I suspect design-by-contract is actually what's really needed, not this notion of "private" code which isn't really private...

Cas Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #58 - Posted 2007-02-09 14:05:06 »

Wouldn't it be sufficient to have a (AOT) bytecode transformer that turns all private/default/protected access modifiers into public?

You feed it a JAR and it spits out a JAR.

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

JGO Ninja


Medals: 52



« Reply #59 - Posted 2007-02-09 14:10:36 »

I think that nearly everybody has realised in practise that OOP isn't about objects and encapsulation, it's just another take on trying to write as little code as possible to do the most work, because at the end of the day, that's all we really care about. Why do we think scripting languages have taken off so fast suddenly? Less code for more work. Little imposition about somebody else's ideas on your own ideas.
Yeah and everytime the developer responsible for this code leaves the company, nobody can fix or change anything because nothing is encapsulated and you never know what side-effects the code has.

This is bad, if the code is inhouse, but disastrous if the code was sold to a customer. They come back and say "hey we just need this little feature" and you take down their whole site while trying to implement it in the timeframe, the customer will pay for. In the end you have rewritten the whole application and only get paid for the added little feature. I've seen that very often and have been there myself. Scripting languages are extremely dangerous for anything else but minimal scripting of a well designed and encapsulated system.

I mean, it's all very well saying "Yes but we're software engineers! I write libraries for other people to use!" But when that other person is me and I can't bloody override something in your library because it's private and hence can't make the bit of code working that I'm working on right now it just annoys the hell out of me!!
I once had the opportunity to use a library where every method and field was public or protected. I was very glad, because every little bug I found could be easily fixed by overriding the protected methods and directly accessing the fields to produce the correct result.

That was five years ago.

Now I still have to use the five years old library with it's five years old features and it's five year old architecture shortcummings. In the meantime there is a more faster, better designed version out there with a lot of nice features I would like to use, but I can't because exchanging the library would mean to rewrite the whole code, that interfaces with the library, because of the missing encapsulation and separation in the first place.

OOP in practice should be about objects and encapsulation, because OOP should be about maintainability.

I suspect design-by-contract is actually what's really needed, not this notion of "private" code which isn't really private...
I really don't know how you can enforce a contract without encapsulation.

Mathias - I Know What [you] Did Last Summer!
Pages: 1 [2] 3 4
  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.

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (43 views)
2014-10-16 15:22:06

Norakomi (33 views)
2014-10-16 15:20:20

lcass (37 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (66 views)
2014-10-14 00:35:47

TehJavaDev (59 views)
2014-10-14 00:32:37

BurntPizza (73 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45

BurntPizza (85 views)
2014-10-11 22:30:10
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!