|
We were not having a reasonable argument because you did not take my constructive criticism as intended. You do not understand the conventions laid out by sun microsystems, which by definition, makes you ignorant.
Ryley included a perfectly valid use case where the java.awt.Point class provides mutators/accessors, breaking the rule of immutability. Conventions are not vague and open to interpretation.You love to talk about these conventions that java has regarding the naming of constants, but I have yet to see any list of constants that testifies to your viewpoint and not testify to mine. There is a reason they are vague and open to interpretation.
This isn't about preference, this is about convention. This is where your problem lies, as indicated in the paragraph above.I think it should be named like a constant
The fact that there has been this much informative discussion relays the fact that you are still ignorant in this respect because you have displayed that you do not understand the underlying problem that is immutable naming to mutable variables.I think it should be named like a constant if it will not change ever, regardless of if it CAN change. According to ryley, that makes me ignorant.
To move forward, It's okay to be wrong about something. Consider that your idea that preference outweighs convention is wrong in this respect, and learn from this.
I am completely open to learning, but my viewpoint will not change unless I see a very specific convention that supports your guys' viewpoint.
The only thing I see is "class constants should be NAMED_LIKE_THIS. I have seen no convention that explains certain circumstances such as specifically saying "a constant in java is something that absolutely cannot change."
Jason and ryley, I am sorry I come across as ignorant but whether you will admit it or not(you won't) this is personal preference.
I an not trying to disrespect either of you guys because you are both great programmers but this is something that you cannot really press upon others.
https://docs.oracle.com/javase/tutor...immutable.html
An object is considered immutable if its state cannot change after it is constructed.That reference or source is literally from the oracle website.Code:static final Point WHAT_IS_THE_POINT = new Point(); WHAT_IS_THE_POINT.x = 5;// STATE HAS CHANGED
No, they're not the same thing, but an immutable member must be constant where a constant doesn't have to be immutable when it comes to naming conventions.
i.e
Code:private final List<Integer> fooConstant = Arrays.asList(1); // an effectively final member due to final modifier, however still mutable. private static final List<Integer> FOO_IMMUTABLE = ImmutableList.of(1); // this is an immutable, effectively final member.
That all depends on the implementation of a 'position'. If you declare something as constant you aren't signifying that it's immutable, just constant. A lot of the time this is perfectly fine, however lets use an example. Lets say that position class is called Position. If that Position class contained methods in which changed the internal state of a Position object, then it shouldn't be defined as immutable ever. Here is an example of a mutable Position class.
Now with this mutable Position class, lets assume you're defining a Position which represents a 'home' location.Code:public class Position { private int x; private int y; private int z; public Position(int x, int y, int z) { this.x = x; this.y = y; this.z = z; } public void setX(int x) { this.x = x; } public void setY(int y) { this.y = y; } public void setZ(int z) { this.z = z; } }
That effectively final, immutably named variable HOME is mutable, so it cannot have this naming.Code:private static final Position HOME = new Position(3200, 3200, 0);
Code:HOME.setX(3201); // unfortunately this is allowed, but it's naming suggests it's immutable? See why this doesn't make sense.This makes much more sense since we know that we can modify the position of home at anytime.Code:private static final Position home = new Position(3200, 3200, 0);
To ensure the class is immutable, we need to provide an immutable representation of it.Code:home.setX(3201); home.setY(3201); home.setZ(1);
Now we can define home as a ImmutablePosition and give it a name following naming conventions.Code:public final class ImmutablePosition extends Position { public Position(int x, int y, int z) { super(x, y, z); } @Override public void setX(int x) { throw new UnsupportedOperationException("Cannot change x value, this is immutable."); @Override public void setY(int y) { throw new UnsupportedOperationException("Cannot change y value, this is immutable."); @Override public void setZ(int z) { throw new UnsupportedOperationException("Cannot change z value, this is immutable."); }
Now any attempt to set the values of HOME will result in a UnsupportedOperationException (iirc thats the proper name). Effectively making this Position immutable.Code:private static final Position HOME = new ImmutablePosition(3200, 3200, 0);
Code:HOME.setX(3201); // throws UnsupportedOperationException
Okay I definitely understand what you're saying and I so agree that it depends on the situation.
My argument was kinda hard on the fact that I was getting annoying with people around here parroting back the argument "well that's technically mutable so the declaration is wrong"
I believe there is situations where it is mutable but should still follow constant declaration
Anywho, thanks for clearing up some things
« Previous Thread | Next Thread » |
Thread Information |
Users Browsing this ThreadThere are currently 1 users browsing this thread. (0 members and 1 guests) |