Thread: Points Base

Page 5 of 7 FirstFirst ... 34567 LastLast
Results 41 to 50 of 63
  1. #41  
    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 guess that is where we disagree.

    Thanks nonetheless for clearing some things up for me.
    It's like talking to a brick wall.
    Reply With Quote  
     

  2. #42  
    PokeFrontier Java Developer

    Pokemon's Avatar
    Join Date
    May 2011
    Posts
    2,726
    Thanks given
    495
    Thanks received
    807
    Rep Power
    1260
    Quote Originally Posted by Andys1814 View Post
    I guess that is where we disagree.

    Thanks nonetheless for clearing some things up for me.
    CONVENTIONS!!!!!!!!!!!!!!!!!!!!!!!!!

    They are very important!!!!!! It's setting a standard in a programming language, imagine working in a group and you were naming all of your objects in capitalized letters or using underscores instead of camel casing would make it very confusing for others. If you decide to modify the standard java conventions make sure you document it for others working within your team, remember communication is key.

    Let me explain this myself

    Let's say i made a home location

    Code:
    public static final Location HOME_LOCATION = Location.create(23, 50);
    that's a constant, now you may change that WHILE YOUR PROGRAM IS NOT RUNNING you may change those values manually and recompile your program, BUT when my program is running I CANNOT CALL

    Code:
    HOME_LOCATION = Location.create(10,0);
    JAVA WILL NOT LET ME, this is a constant it's expected to stay that way as long as the program is running.

    Mutable classes can have its internal variables changed while the program is running so having their coordinate values should be mutable and that's completely fine since it's a variable that's expected to change

    Immutable classes are not supposed to have its internal variables change, it's purpose is to be created once and it stays that way! so you can only have getters for that, a good example would be creating the size of a model on a man NPC, that should stay as is once that NPC has been created or a player id. There are many examples for this, i suggest searching some information on stack overflow, they have great examples


    Attached image


    I love
    Reply With Quote  
     

  3. Thankful user:


  4. #43  
    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
    It's like talking to a brick wall.
    ? I was genuinely thanking you for clearing up some of my questions . I guess I am not entitled to my own opinion as you stated earlier in this thread.

    I've already said everything on my mind so if you want a response then look at my previous posts before claiming talking to me is like talking to a brick wall.

    Quote Originally Posted by Pokemon View Post
    CONVENTIONS!!!!!!!!!!!!!!!!!!!!!!!!!

    They are very important!!!!!! It's setting a standard in a programming language, imagine working in a group and you were naming all of your objects in capitalized letters or using underscores instead of camel casing would make it very confusing for others. If you decide to modify the standard java conventions make sure you document it for others working within your team, remember communication is key.

    Let me explain this myself

    Let's say i made a home location

    Code:
    public static final Location HOME_LOCATION = Location.create(23, 50);
    that's a constant, now you may change that WHILE YOUR PROGRAM IS NOT RUNNING you may change those values manually and recompile your program, BUT when my program is running I CANNOT CALL

    Code:
    HOME_LOCATION = Location.create(10,0);
    JAVA WILL NOT LET ME, this is a constant it's expected to stay that way as long as the program is running.

    Mutable classes can have its internal variables changed while the program is running so having their coordinate values should be mutable and that's completely fine since it's a variable that's expected to change

    Immutable classes are not supposed to have its internal variables change, it's purpose is to be created once and it stays that way! so you can only have getters for that, a good example would be creating the size of a model on a man NPC, that should stay as is once that NPC has been created or a player id. There are many examples for this, i suggest searching some information on stack overflow, they have great examples
    Thanks for replying but you may be confused what I am arguing about because I agree with literally everything in your post. I know what a constant is and how it should be named. I know what immutability is too.

    I am arguing that these rules that people make up in their head and feel like they need to use 100% is wrong in my personal opinion. I am talking specifically that people would want to name it "homeLocation" instead of HOME_LOCATION because "I can technically mutate it if I really really want to!"
    Reply With Quote  
     

  5. #44  
    PokeFrontier Java Developer

    Pokemon's Avatar
    Join Date
    May 2011
    Posts
    2,726
    Thanks given
    495
    Thanks received
    807
    Rep Power
    1260
    Quote Originally Posted by Andys1814 View Post
    ? I was genuinely thanking you for clearing up some of my questions . I guess I am not entitled to my own opinion as you stated earlier in this thread.

    I've already said everything on my mind so if you want a response then look at my previous posts before claiming talking to me is like talking to a brick wall.



    Thanks for replying but you may be confused what I am arguing about because I agree with literally everything in your post. I know what a constant is and how it should be named. I know what immutability is too.

    I am arguing that these rules that people make up in their head and feel like they need to use 100% is wrong in my personal opinion. I am talking specifically that people would want to name it "homeLocation" instead of HOME_LOCATION because "I can technically mutate it if I really really want to!"
    if its final it should be all capitalized


    Attached image


    I love
    Reply With Quote  
     

  6. Thankful user:


  7. #45  
    Registered Member
    Andys1814's Avatar
    Join Date
    Feb 2013
    Posts
    974
    Thanks given
    688
    Thanks received
    455
    Rep Power
    727
    Quote Originally Posted by Pokemon View Post
    if its final it should be all capitalized
    This is exactly my opinion. People on here (Ryley and Jason for example) seem to put constants and immutability in the same vein and claim that fields cannot be constant unless they are 100% immutable. I have not seen a document that shows this viewpoint to be true. Jason linked a document that just provided the definition of immutability (which for some reason he thinks I do not know?) which proves nothing.

    In my opinion (which according to the dynamic duo of Jason and Ryley is an opinion that makes me ignorant somehow?), immutable objects are in a completely different vain from constant objects. If an object is declared final, and therefore will not be reassigned, is by definition a constant and should be named as such. They disagree with this and think that a constant is only something that is physically impossible to change. I understand their viewpoint and agree with it in certain situations but I do not generalize it as the case in every single situation.

    The basis of my argument is that it annoys me that people around here try to press their personal preference on others (while denying it is personal preference and instead FACTS!). Contrary to what the two power thinkers think, everyone is entitled to their own opinion. If the conventions mentioned specifically that fields can only be constant if they are IMMUTABLE ALSO, then people shouldn't be entitled to their own opinion -- they should follow the conventions laid out by the language. If someone were to find a convention that states that viewpoint t be true, I would shut up and start conforming to it. But I haven't seen that as of yet.
    Reply With Quote  
     

  8. #46  
    Respected Member


    Join Date
    Jul 2015
    Posts
    781
    Thanks given
    206
    Thanks received
    394
    Rep Power
    524
    Quote Originally Posted by Andys1814 View Post
    I guess that is where we disagree.

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

  9. #47  
    Registered Member
    Andys1814's Avatar
    Join Date
    Feb 2013
    Posts
    974
    Thanks given
    688
    Thanks received
    455
    Rep Power
    727
    Quote Originally Posted by Mayhem_ View Post
    Explain
    Reply With Quote  
     

  10. #48  
    Respected Member


    Join Date
    Jul 2015
    Posts
    781
    Thanks given
    206
    Thanks received
    394
    Rep Power
    524
    Quote Originally Posted by Andys1814 View Post
    Explain
    https://www.scribd.com/doc/15884743/...by-Achut-Reddy
    3.3 Field naming

    or http://stackoverflow.com/a/9510335
    Reply With Quote  
     

  11. #49  
    Registered Member
    Andys1814's Avatar
    Join Date
    Feb 2013
    Posts
    974
    Thanks given
    688
    Thanks received
    455
    Rep Power
    727
    Okay the little convention book you linked literally testified to my viewpoint.

    And the stack-overflow post didn't really provide any information that I wasn't already aware of. I know some references are mutable and CAN change, but it should still be declared a constant if it won't change.

    The stack-overflow was actually a pretty good read though. I liked this comment in particular: java - Should a "static final Logger" be declared in UPPER-CASE? - Stack Overflow
    Reply With Quote  
     

  12. #50  
    Ex Rune-Scaper

    Join Date
    Jun 2008
    Posts
    3,534
    Thanks given
    457
    Thanks received
    1,257
    Rep Power
    990
    Quote Originally Posted by Pokemon View Post
    if its final it should be all capitalized
    no.. because objects marked final can still be mutable. the "final" keyword is regarding the object's reference not it's contents. primitive types marked final are immutable because they become constants.

    Code:
    public final class ImmutableNumber <T extends Number> {
        
        private final T value; 
    
        private ImmutableNumber(T value) {        
            this.value = value;
        }
        
        public static ImmutableNumber<Integer> create(int value) {
            return new ImmutableNumber<Integer>(value);
        }
        
        public static ImmutableNumber<Float> create(float value) {
            return new ImmutableNumber<Float>(value);
        }
        
        public static ImmutableNumber<Double> create(double value) {
            return new ImmutableNumber<Double>(value);
        }
        
        public static ImmutableNumber<Long> create(long value) {
            return new ImmutableNumber<Long>(value);
        }
        
        public T getValue() {
            return value;
        }
    
    
    }
    Code:
    public final class MutableNumber <T extends Number> {
        
        private T value;
    
        public MutableNumber(T value) {
            this.value = value;
        }
        
        public T getValue() {
            return value;
        }
        
        public void setValue(T value) {
            this.value = value;
        }
    
    
    }
    Code:
        // immutable objects
        
        static final ImmutableNumber<Double> IMMUTABLE_DOUBLE = ImmutableNumber.create(100.00);
        
        static final ImmutableNumber<Float> IMMUTABLE_FLOAT = ImmutableNumber.create(10.00F);
        
        static final ImmutableNumber<Integer> IMMUTABLE_INTEGER = ImmutableNumber.create(100);
        
        static final ImmutableNumber<Long> IMMUTABLE_LONG = ImmutableNumber.create(100000000L);
        
        // mutable objects
        
        static final MutableNumber<Double> mutableDouble = new MutableNumber<>(100.00);
        
        static final MutableNumber<Float> mutableFloat = new MutableNumber<>(10.00F);
        
        static final MutableNumber<Integer> mutableInteger = new MutableNumber<>(100);
        
        static final MutableNumber<Long> mutableLong = new MutableNumber<>(100000000L);
    
        public static void main(String[] args) {
            
            // can't change the "ImmutableNumber" objects state once its created, can only get the value. so the
            // "ImmutableNumber" object is said to be immutable. also note all primitive wrappers are immutable as well, so you don't even need an implementation of this class.
            // if you want extra functionality you can use the primitive type wrapper classes such as Integer, Long, etc.. If you only want the value, just use the primitive type. If you wanted additional functionality then you would need to do something like this.
            IMMUTABLE_INTEGER.getValue();
            
            // changed the objects state, so the "MutableNumber" object is said to be mutable.
            mutableInteger.setValue(10000);        
            
        }
    Reply With Quote  
     

  13. Thankful user:


Page 5 of 7 FirstFirst ... 34567 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
  •