Thread: Points Base

Page 4 of 7 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 63
  1. #31  
    Donator

    Jason's Avatar
    Join Date
    Aug 2009
    Posts
    6,092
    Thanks given
    2,402
    Thanks received
    2,823
    Rep Power
    4550
    Quote Originally Posted by Andys1814 View Post
    I don't see how you can come and talk about these topics as if you are talking about facts. It's literally personal preference and me and Jason were actually having a reasonable argument, I'm not sure how my statements make me ignorant.
    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.

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

    I think it should be named like a constant
    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 if it will not change ever, regardless of if it CAN change. According to ryley, that makes me ignorant.
    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.

    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.
    Reply With Quote  
     

  2. Thankful user:


  3. #32  
    Registered Member
    Andys1814's Avatar
    Join Date
    Feb 2013
    Posts
    974
    Thanks given
    688
    Thanks received
    455
    Rep Power
    727
    Quote Originally Posted by Jason View Post
    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.


    This isn't about preference, this is about convention. This is where your problem lies, as indicated in the paragraph above.


    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.

    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.
    Reply With Quote  
     

  4. #33  
    Donator

    Jason's Avatar
    Join Date
    Aug 2009
    Posts
    6,092
    Thanks given
    2,402
    Thanks received
    2,823
    Rep Power
    4550
    Quote Originally Posted by Andys1814 View Post
    very specific convention that supports your guys
    https://docs.oracle.com/javase/tutor...immutable.html

    An object is considered immutable if its state cannot change after it is constructed.
    Code:
    static final Point WHAT_IS_THE_POINT = new Point();
    
    WHAT_IS_THE_POINT.x = 5;// STATE HAS CHANGED
    That reference or source is literally from the oracle website.
    Reply With Quote  
     

  5. #34  
    Registered Member
    Andys1814's Avatar
    Join Date
    Feb 2013
    Posts
    974
    Thanks given
    688
    Thanks received
    455
    Rep Power
    727
    Quote Originally Posted by Jason View Post
    https://docs.oracle.com/javase/tutor...immutable.html



    Code:
    static final Point WHAT_IS_THE_POINT = new Point();
    
    WHAT_IS_THE_POINT.x = 5;// STATE HAS CHANGED
    That reference or source is literally from the oracle website.
    I see. This is actually a genuine question I want to ask:

    Is an immutable variable the same thing as a constant?
    Reply With Quote  
     

  6. #35  
    Donator

    Jason's Avatar
    Join Date
    Aug 2009
    Posts
    6,092
    Thanks given
    2,402
    Thanks received
    2,823
    Rep Power
    4550
    Quote Originally Posted by Andys1814 View Post
    I see. This is actually a genuine question I want to ask:

    Is an immutable variable the same thing as a constant?
    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.
    Reply With Quote  
     

  7. #36  
    Registered Member
    Andys1814's Avatar
    Join Date
    Feb 2013
    Posts
    974
    Thanks given
    688
    Thanks received
    455
    Rep Power
    727
    Quote Originally Posted by Jason View Post
    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.
    Alright.
    So you don't think a constant such as a starting position on an rsps (x, y, z coordinate that WILL NEVER CHANGE) should follow constant declaration?

    I just feel like it's much more clear as to the intention of the developer if it is named constsnt.
    Reply With Quote  
     

  8. #37  
    Donator

    Jason's Avatar
    Join Date
    Aug 2009
    Posts
    6,092
    Thanks given
    2,402
    Thanks received
    2,823
    Rep Power
    4550
    Quote Originally Posted by Andys1814 View Post
    Alright.
    So you don't think a constant such as a starting position on an rsps (x, y, z coordinate that WILL NEVER CHANGE) should follow constant declaration?

    I just feel like it's much more clear as to the intention of the developer if it is named constsnt.
    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.

    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;
        }
    }
    Now with this mutable Position class, lets assume you're defining a Position which represents a 'home' location.

    Code:
    private static final Position HOME = new Position(3200, 3200, 0);
    That effectively final, immutably named variable HOME is mutable, so it cannot have this naming.

    Code:
    HOME.setX(3201); // unfortunately this is allowed, but it's naming suggests it's immutable? See why this doesn't make sense.
    Code:
    private static final Position home = new Position(3200, 3200, 0);
    This makes much more sense since we know that we can modify the position of home at anytime.

    Code:
    home.setX(3201);
    home.setY(3201);
    home.setZ(1);
    To ensure the class is immutable, we need to provide an immutable representation of it.

    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 we can define home as a ImmutablePosition and give it a name following naming conventions.

    Code:
    private static final Position HOME = new ImmutablePosition(3200, 3200, 0);
    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:
    HOME.setX(3201); // throws UnsupportedOperationException
    Reply With Quote  
     

  9. Thankful user:


  10. #38  
    Registered Member
    Andys1814's Avatar
    Join Date
    Feb 2013
    Posts
    974
    Thanks given
    688
    Thanks received
    455
    Rep Power
    727
    Quote Originally Posted by Jason View Post
    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.

    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;
        }
    }
    Now with this mutable Position class, lets assume you're defining a Position which represents a 'home' location.

    Code:
    private static final Position HOME = new Position(3200, 3200, 0);
    That effectively final, immutably named variable HOME is mutable, so it cannot have this naming.

    Code:
    HOME.setX(3201); // unfortunately this is allowed, but it's naming suggests it's immutable? See why this doesn't make sense.
    Code:
    private static final Position home = new Position(3200, 3200, 0);
    This makes much more sense since we know that we can modify the position of home at anytime.

    Code:
    home.setX(3201);
    home.setY(3201);
    home.setZ(1);
    To ensure the class is immutable, we need to provide an immutable representation of it.

    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 we can define home as a ImmutablePosition and give it a name following naming conventions.

    Code:
    private static final Position HOME = new ImmutablePosition(3200, 3200, 0);
    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:
    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
    Reply With Quote  
     

  11. #39  
    Donator

    Jason's Avatar
    Join Date
    Aug 2009
    Posts
    6,092
    Thanks given
    2,402
    Thanks received
    2,823
    Rep Power
    4550
    Quote Originally Posted by Andys1814 View Post
    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
    I wan't to clarify by stating that these conventions should ALWAYS be followed and that it DOESN'T depend on the situation.
    Reply With Quote  
     

  12. #40  
    Registered Member
    Andys1814's Avatar
    Join Date
    Feb 2013
    Posts
    974
    Thanks given
    688
    Thanks received
    455
    Rep Power
    727
    Quote Originally Posted by Jason View Post
    I wan't to clarify by stating that these conventions should ALWAYS be followed and that it DOESN'T depend on the situation.
    I guess that is where we disagree.

    Thanks nonetheless for clearing some things up for me.
    Reply With Quote  
     

Page 4 of 7 FirstFirst ... 23456 ... LastLast

Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


User Tag List

Similar Threads

  1. Replies: 37
    Last Post: 06-28-2014, 12:33 PM
  2. [BASE] User Titles. (e.g loyalty point things)
    By Robin Spud in forum Tutorials
    Replies: 29
    Last Post: 12-31-2011, 12:34 AM
  3. Replies: 45
    Last Post: 05-02-2011, 06:06 PM
  4. in-game highscores based on points
    By Oxygen in forum Help
    Replies: 1
    Last Post: 05-06-2009, 05:37 PM
  5. [HUGE] Charecter based sig (C) [HUGE]
    By Looted in forum Tutorials
    Replies: 15
    Last Post: 05-20-2007, 05:23 PM
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •