Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (483)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
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 21224 times)
0 Members and 1 Guest are viewing this topic.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #90 - Posted 2007-02-15 05:11:32 »

Either using public fields or simple getters and setters, it's not encapsulating anything! Most people use beans as simple containers of data, why not to make all fields public? What do you think you are "encapsulating" by making a get/set?

Getters and Setters are needed in many cases.
Why?
-for validity checks
-for property change notifications
-to add a layer of protection so you can keep the same interface (contract?) but change the implementation as needed

I'm generally against the buzz around adding "true" properties to the Java language...  I just don't see the problem with the way things are now.  writing getters and setters coudl be tedious - if anyone still does that by hand... IDEs generally do it for you, and then of course you fill in the extra bits that a built-in property feature can't handle anyway  (e.g. range/security checks, logging, etc.).

Making everything public may let you patch a library.. but then it cripples the library author's ability to make changes that don't break your code.

BTW for #4 in Cas' original list.. Did anyone catch the recent library mentioned on java.net  https://nlink.dev.java.net/.  It looks very interesting to me.

Offline TimRyanNZ

Junior Newbie





« Reply #91 - Posted 2007-02-15 08:44:45 »

Well why can't Java syntax be made that allows you to silently intercept direct variable accesses and pass them through a setter/getter.  Then we get the best of both worlds.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 781
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #92 - Posted 2007-02-15 11:38:56 »

AKA properties in C# Smiley

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 Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #93 - Posted 2007-02-15 11:49:26 »

I'm starting to think that MS made a really good decision to separate out the bytecode / CLR section of .Net from the actual language specifications (eg. C#). That way everyone can go off and make their own crazy modifications to the actual languages without forcing them down everyones throat. You could have Java++ with operator overloading, proper const, null checking at compile time, etc. At the moment we get a half-way version of this where people stick with a particular Java version instead.

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

Junior Member





« Reply #94 - Posted 2007-02-15 13:01:18 »

I'm starting to think that MS made a really good decision to separate out the bytecode / CLR section of .Net from the actual language specifications (eg. C#). That way everyone can go off and make their own crazy modifications to the actual languages without forcing them down everyones throat. You could have Java++ with operator overloading, proper const, null checking at compile time, etc. At the moment we get a half-way version of this where people stick with a particular Java version instead.

why cant ide's do these things?

desperately seeking sanity
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #95 - Posted 2007-02-15 14:13:04 »

Er, they can, that's what this thread is all about Smiley If we could tweak the language a bit, what would we do? And then somebody might whip up a compiler for it in Eclipse and see how it fares.

Cas Smiley

Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #96 - Posted 2007-02-15 20:12:13 »

Well why can't Java syntax be made that allows you to silently intercept direct variable accesses and pass them through a setter/getter.  Then we get the best of both worlds.

*shudder* operator overloading is a path to the darkside!

Any time someone has a bright idea on how to obfuscate the meaning of the java syntax,
I think they should be forced to go back to school and teach the java syntax to programmer noobies for a week!

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 #97 - Posted 2007-02-16 02:12:29 »

Well why can't Java syntax be made that allows you to silently intercept direct variable accesses and pass them through a setter/getter.  Then we get the best of both worlds.

Not really... then you get mysterious side effects when you thought you were doing a simple assignment. Also, how would you implement the setter without making it infinitely recursive? :-)

Getters and setters are part of a pattern that is so well recognised that it is natural for Java programmers.  Changing that isn't really helping anyone.  IDEs do most of the typing for you,so saving a few keystrokes is almost 100% irrelevant.  It also is a great feature to be able to type myVar.set<ctrl-space> and get a pop-up list of all the things that I'm allowed to set on that class.  What happens to that awesome auto-documentation showing super timesaver when suddenly I'm forced to wade through everything because there are no setters anymore?

Nobody commented on NLink.  I thought it was a really great way to do JNI and I think there would be a much greater pay-off if something like it, or better, was integrated into Java to improve the whole JNI experience.

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #98 - Posted 2007-02-16 14:25:59 »

Integrated directly into Java would be great.

Cas Smiley

Offline thiagosc2

Senior Newbie





« Reply #99 - Posted 2007-02-25 00:45:18 »

You don't get what I am saying, nor the cool thing about C# properties.

In JAVA you have to create a get and set to encapsulate your data. A class that provides a get does not have to just pass back a reference. It could generate an object on the fly etc. Or when a set is called you could notify listeners the state has changed. In java if you make all your fields public (which I often do becuase I am lazy), you can never encapsulate the state of those objects at a later date. 

However, in C# you can be lazy i.e. Create public variables initially. When your design has evoleved and you need to either refactor out the variable or replace the storage mechanism or add an event model or whatever, you simply replace the variable with a property. Properties look syntactically exactly the same as variables. So no source code outside needs to be changed (becuase of the strong form of auto-boxing C# implements), however you can write a specialized set and get for it, it does not even need to delagate to a variable for storage of anything. They are just like mini classes, so your design can evolve unhindered.

This is exactly what encapsulation is about, hiding your internals, so it doesn't matter how you actually carry out requests. C# allows you to do this at essentially the variable assignment and retrieval level, where as java can only do it at a method invocation level.

Wait a minute, you are NOT encapsulating anything by adding a getter/setter. Getters/setters don't give you magically "encapsulation" by their mere existence alone. How can you be hiding something and providing a getter/setter at the same time? Is this a quantum computer? This is like saying the bit is 0 and 1 at the same time, you are going down and up the stairs at the same time, you are in and out of the house at the same time!

If you want to do validation then a method is the ideal place for it, since it will perform some logic. Besides, with properties the developer can't tell if that is a public field or a private one, it means, he won't be able to understand the code just by looking at it, because it might call a method or not.

This is just overloading the meaning of the operator '=', the same problems of not being to tell what is going on will happen. Operator overloading? That's how it should be called.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Don Kiddick

Junior Member





« Reply #100 - Posted 2007-02-26 13:42:40 »

#1 get rid of primitives - unboxing where possible should be a compiler problem.  Number types would behave like strings, so would have operators like + and - minus defined. I could therefore do this :
1  
2  
Integer five = 5;
Integer ten = 5 * 2; //Equivalent to five.multiplyBy(2);


Would mean methods like the 4 Math.abs methods could be reduced to one.

#2 I would have standard date class(es) that are much better like the pig's ear that is Date and Calendar.

#3 I would have a way of removing boilerplate code - bound properties, closing resources that throw checked exceptions etc... The proposals for closures seem to promise this but I'm undecided as yet.

D.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #101 - Posted 2007-02-26 14:38:39 »

#1 get rid of primitives - unboxing where possible should be a compiler problem.  Number types would behave like strings, so would have operators like + and - minus defined. I could therefore do this :
1  
2  
Integer five = 5;
Integer ten = 5 * 2; //Equivalent to five.multiplyBy(2);



I've got mixed feelings about this: Maybe things get more consistent on one hand (everything objects), but it also makes the syntax less consistent on the other.
And which problem does this solve?

At least your syntax proposal makes things less consistent as I feel it probably should become something like:
1  
2  
3  
4  
Integer five = new Integer(5);
Integer ten = new Integer(5 * 2);
or even
Integer ten = new Integer(5).multiplyBy(new Integer(2));


More consistent, but less readable of course :-)

And I think the compiler will have a hard time getting the same performance out of something like this instead of primitives. I feel lots of object overhead coming our way, String-like constant pools, more strain on the GC and other things I don't want.
My opinion is that I'm doing enough number crunching that I want my calculations to be:
a) readable
b) fast, with guaranteed no object overhead whatsoever (I'm not sure a compiler would be able to get rid of that overhead in all cases).

And again, what do you gain by having primitives as Objects? If it's collections and such, there's already autoboxing there (which introduced a couple of new performance pitfalls).
Math, numbers etc are such a well defined concept that I personally don't see any benefit in having them represented as objects.

Unless maybe I'm missing your point? If so, do explain :-)

Offline Mr_Light

Senior Member




shiny.


« Reply #102 - Posted 2007-02-26 23:12:38 »

#2 I would have standard date class(es) that are much better like the pig's ear that is Date and Calendar.

have you seen http://jcp.org/en/jsr/detail?id=310 ?

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 Don Kiddick

Junior Member





« Reply #103 - Posted 2007-02-27 08:25:42 »

I've got mixed feelings about this: Maybe things get more consistent on one hand (everything objects), but it also makes the syntax less consistent on the other.
And which problem does this solve?

At least your syntax proposal makes things less consistent as I feel it probably should become something like:
1  
2  
3  
4  
Integer five = new Integer(5);
Integer ten = new Integer(5 * 2);
or even
Integer ten = new Integer(5).multiplyBy(new Integer(2));


More consistent, but less readable of course :-)


Your counter example still appears to have primitives (the arguements for the constructors).
In terms of consistency the analogy would be String :
1  
String s = "blah";


Quote
And which problem does this solve?
Two I think.
#1 if I write a bit of number crunching code, and I don't care whether the parameters are floats or doubles (or in fact ints or longs), I can define those parameters to be the Number class. I can then write readable math code using +*/-. The compiler could under-the-hood turn stuff into primitives to make it just as fast.
I imagine there is lots of game code out there that has primitive types in their signatures, changing from say float to double could be very painful but this way it wouldn't.
Taking it further you could define interfaces such as Addable, Divisible etc.. so more complex objects such as Vectors could participate. Where this descends into operator overloading I'm not sure.

#2 Methods that take any input, currently have to have a version for Object plus all the primitive types. e.g JUnits assertEquals, could be condensed from 20 to 2 methods.


Quote
And I think the compiler will have a hard time getting the same performance out of something like this instead of primitives.
My idea is that the compiler would be more clever and be able to convert to primitives where necessary. However I don't write compilers so I don't know if this is feasible.

Thoughts?
D.


 
Offline cylab

JGO Ninja


Medals: 43



« Reply #104 - Posted 2007-02-27 09:42:52 »

#1 get rid of primitives - unboxing where possible should be a compiler problem.  Number types would behave like strings, so would have operators like + and - minus defined. I could therefore do this :
1  
2  
Integer five = 5;
Integer ten = 5 * 2; //Equivalent to five.multiplyBy(2);

You are aware, that the above compiles fine with 1.5, are you? The only difference is, that the second line is not equivalent to five.multiplyBy(2) but to Integer ten= new Integer(5*2), but since you can even write
1  
2  
3  
   Integer five= 5;
   Integer two= 2;
   Integer ten= five*two;

I think this doesn't matter...

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

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #105 - Posted 2007-02-27 12:17:39 »

#1 if I write a bit of number crunching code, and I don't care whether the parameters are floats or doubles (or in fact ints or longs), I can define those parameters to be the Number class. I can then write readable math code using +*/-. The compiler could under-the-hood turn stuff into primitives to make it just as fast.
I imagine there is lots of game code out there that has primitive types in their signatures, changing from say float to double could be very painful but this way it wouldn't.
Taking it further you could define interfaces such as Addable, Divisible etc.. so more complex objects such as Vectors could participate. Where this descends into operator overloading I'm not sure.

#2 Methods that take any input, currently have to have a version for Object plus all the primitive types. e.g JUnits assertEquals, could be condensed from 20 to 2 methods.

My idea is that the compiler would be more clever and be able to convert to primitives where necessary. However I don't write compilers so I don't know if this is feasible.

And there goes strong type checking out the window.

Offline Breakfast

Senior Member




for great justice!


« Reply #106 - Posted 2007-02-27 14:43:16 »

Quote
And there goes strong type checking out the window.
Most things running on the JVM a couple of years from now will be scripting languages anyways. A Number class as described would be exactly the kind of thing they will need.
Offline Don Kiddick

Junior Member





« Reply #107 - Posted 2007-02-27 17:15:56 »

And there goes strong type checking out the window.

How so? I would call it 'using a higher layer of abstraction'

Most games do a load of maths with say floats. The code doesn't really care it's using floats - it would look the same if it were crunching doubles. Therefore if you could write your methods using a higher level abstraction, e.g. Number it would work for both floats and doubles. Therefore if you decide to change your game to use doubles instead of vice-versa, it is much easier. Also library code written this way could be used for games that uses doubles or floats - it is more reusable.
Of course to do this, you need to not use primitives as they are not polymorphic.

D.
Offline Don Kiddick

Junior Member





« Reply #108 - Posted 2007-02-27 17:16:42 »

Most things running on the JVM a couple of years from now will be scripting languages anyways. A Number class as described would be exactly the kind of thing they will need.

Apart from the operator overloading, it exists - java.lang.Number
Offline CommanderKeith
« Reply #109 - Posted 2007-03-02 06:07:28 »

Something I found today about calling DLL's without JNI:

https://jna.dev.java.net/

But I haven't looked into it (nor can I ever see myself using it  Tongue).

Offline gideon

Senior Newbie





« Reply #110 - Posted 2007-03-05 09:33:53 »

And there goes strong type checking out the window.

While this is true for java's type system as it is, it is not necessarily true in general. There are strong type systems where you don't have to decide whether you're using floats or ints in an expression, this is inferred by the compiler automatically. Some functional languages like Haskell have this feature and it works great (in most situations). This feature is called type classes which has nothing to do with OO-classes.

For example 34 + 4 * 2 would have a type (Num a) => a, which tells us that it gives us a polymorphic type a (any type a), wich is in the 'Num' class. Had I used a 'floating point' somewhere, e.g. 34 + 4 * 2.2, the type would've been (Num a, Fractional a) => a. Note that Fractional also implies Num, so one can leave out the 'Num' class.

You might be right for #2 ("Methods that take any input, currently have to have a version for Object plus all the primitive types. e.g JUnits assertEquals, could be condensed from 20 to 2 methods"). I don't understand what exactly he wants to have here, so it would be hard to judge wether it would be possible with a strong type system.

--gideon

The towship's adventures
Offline Don Kiddick

Junior Member





« Reply #111 - Posted 2007-03-09 08:01:07 »

This is my problem :

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
final class Range {
  private final Number min;
  private final Number max;

  Range(Number min, Number max) {
    this.min = min;
    this.max = max;
  }

  public Number size() {
    //How to implement?
   // return max.minus(min); //would be nice
   // return max.doubleValue() - min.doubleValue(); //Loses accuracy on not floating point types
 }
}


I want this class to work for int, floats, doubles, BigIntegers, bytes etc... So if my range is an int range (min and max are ints) then size returns an int, if my range is a double range, then size returns a double. How do I implement the size method?
The ways I can see are ugly - mutliple implementations of the size method either as subclasses or a big if statement - yuck.
This is not an isolated problem, check out Rectangle, Rectangle2D.Double,and Rectangle2D.Float and Point, Point2D.Double and Point2D.Float.

This ugly, verbose and error prone and I would change it.

D.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #112 - Posted 2007-03-30 12:09:10 »

What I would really like is the 'unsigned' keyword, and to change the fact that all kinds of operations are always implicitly cast to int.
For example I want to be able to write:
1  
unsigned byte someByte = someOtherByte << 1;

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #113 - Posted 2007-03-30 13:24:06 »

Oooh, wouldn't it also be totally excellent to have binary, byte and short literals too?
eg.
1  
2  
3  
byte b = 245b;
short s = 1234s;
int wibble = %100101010111;


Cas Smiley

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #114 - Posted 2007-03-30 14:46:19 »

Yes, having to write
1  
byte b = (byte) 254;

is just annoying.

Offline f.l.x

Senior Member


Projects: 3


there is no place like 127.0.0.1


« Reply #115 - Posted 2007-04-01 22:02:26 »

bynary annotation, like byte b = %01101100

an interactive shell like python has.

Litterarum radices amaras, fructus dulces
http://flx.proyectoanonimo.com
figth spam!
Offline noblemaster

JGO Ninja


Medals: 20
Projects: 10


Age of Conquest makes your day!


« Reply #116 - Posted 2007-04-01 23:14:56 »

Quote
This is my problem :

Code:

final class Range {
  private final Number min;
  private final Number max;

  Range(Number min, Number max) {
    this.min = min;
    this.max = max;
  }

  public Number size() {
    //How to implement?
    // return max.minus(min); //would be nice
    // return max.doubleValue() - min.doubleValue(); //Loses accuracy on not floating point types
  }
}


I want this class to work for int, floats, doubles, BigIntegers, bytes etc... So if my range is an int range (min and max are ints) then size returns an int, if my range is a double range, then size returns a double. How do I implement the size method?
The ways I can see are ugly - mutliple implementations of the size method either as subclasses or a big if statement - yuck.
This is not an isolated problem, check out Rectangle, Rectangle2D.Double,and Rectangle2D.Float and Point, Point2D.Double and Point2D.Float.

This ugly, verbose and error prone and I would change it.

How about:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
final class Range<N extends Number> {
  private final N min;
  private final N max;

  Range(N min, N max) {
    this.min = min;
    this.max = max;
  }

  public N size() {
    return (N)(max - min);
  }
}

I didn't compile it; so there might be problems.

Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #117 - Posted 2007-04-02 00:56:01 »

How about:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
final class Range<N extends Number> {
  private final N min;
  private final N max;

  Range(N min, N max) {
    this.min = min;
    this.max = max;
  }

  public N size() {
    return (N)(max - min);
  }
}

I didn't compile it; so there might be problems.


You'd think that would work, wouldn't you - shame autoboxing was implemented as a hacky after-thought.
The '-' operator is defined for all of the Number classes sub-classes, but not for the Number class itself, hence it doesn't compile.

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

Junior Member





« Reply #118 - Posted 2007-04-03 10:04:40 »

Would it make sense to add abstract minus, mulitply and add methods to Number? e.g :

1  
2  
3  
4  
class Number {
  public abstract <T extends Number> T minus(T other);
  //Similarly add and multiple
}


1  
2  
3  
4  
5  
6  
class Integer {
    public Integer minus(Integer i) {
      return valueOf(intValue() - i.intValue()); //preserving immutabilitiy
   }
  //Similarly add and multiple
}


1  
2  
3  
4  
5  
6  
class Double {
    public Integer minus(Double d) {
      return valueOf(doubleValue() - d.doubleValue()); //preserving immutabilitiy
   }
  //Similarly add and multiple
}


Not compiled this either, but I think it works and it makes sense to me to have such operations on the Number class, in fact they seem conspicuous by there absence.  Comments welcomed.
D.
Offline noblemaster

JGO Ninja


Medals: 20
Projects: 10


Age of Conquest makes your day!


« Reply #119 - Posted 2007-04-03 10:17:11 »

I think that makes a lot of sense! Or provide an utility class...

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.

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

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

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

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

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

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

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

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

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38
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!