Jump to content
Frequently Asked Questions
  • Are you not able to open the client? Try following our getting started guide
  • Still not working? Try downloading and running JarFix
  • Help! My bot doesn't do anything! Enable fresh start in client settings and restart the client
  • How to purchase with PayPal/OSRS/Crypto gold? You can purchase vouchers from other users
  • Why null is becoming scarce (and my thoughts on it)


    Dioxin

    Recommended Posts

    This may not be exactly what you're talking about, but I know in Python, rather than if var == null you have if var is None

     

    Which works if you have an empty array (I think) and empty strings etc. (I haven't really tested how deep None goes in a while, forgive me if I'm mistaken)

    But personally, I like null. It's more of a personal thing though, as I like to be 100% sure that something doesn't exist.

    That and if there isn't a consistent use of what is/isn't "existing" (empty arrays, empty strings rather than just null) then soon if statements from methods end up being

    String a = yourMethodThing();

    if(a == null || a.equals("") || a.equals("null"))

     

    Thus adding more areas of "what could go wrong?" and ending up with duplicate, unnecessary code.

     

    I did enjoy reading this (I'll be honest, I skimmed a lot of it because I'm trying to get motivated to do homework and don't have time to really read it), and will probably reread it again later. (inb4 I'm completely off on what I'm talking about and now I look like a fool)

    Thanks for posting. :D

    There are 2 reasons you would perform a null-check:

     

    1. To lazily initialize a variable (variables that are only initialized when first used; saves memory)

     

    2. To do nothing (if it's null, it's empty and we dont wanna do anything for the empty value; do nothing)

     

    Creating a new conditional statement to "do nothing if there's no value" is pretty tedious, especially if you're using a variable that might contain null in many different places.

     

    Instead, if a default value was used, which had the behavior of doing nothing, you could remove the need for null-checks.

     

    To give an example, lets say you were putting animals into cages. You have a cage and you have an animal.

    Cage cage = new Cage();Animal[] animals = {     new Dog(),     new Cat(),     null,     new Dog();};
    Our array has 1 empty variable (null). Since there is a null in there, we must perform a null-check to prevent NullPointerExceptions:

    for(Animal animal : animals) {    if(animal != null)        animal.putInCage(cage);}
    Easy enough. But if we instead replaced null with our own default value, we could get the same effect without a null check:

    Animal[] animals = {     new Dog(),     new Cat(),     new NoAnimal(),     new Dog();};for(Animal animal : animals)     animal.putInCage(cage);
    When the NoAnimal instance is used, nothing happens (like we wanted) since the putInCage method for NoAnimal does nothing (as shown below). This gives us the same logic that we wanted, without the need for a null-check.
    abstract class Animal {     public abstract void putInCage(Cage cage);}class Dog extends Animal {     public void putInCage(Cage cage) {          System.out.println("The dog whimpes as it goes in the cage");     }}class Cat extends Animal {     public void putInCage(Cage cage) {          System.out.println("The cat hisses as it goes in the cage");     }}class NoAnimal extends Animal {     public void putInCage(Cage cage) {          //does nothing     }}

    You still need a check to continue - that's what my point is. If I'm going to check, I'd rather it be null, rather than expensive CPU cycles for something that could be iterated trillions of times during a simulation

    You actually don't; check out my example. The check is not needed since we already know we want to "do nothing" (or perform some other default behavior). Since we already know that, we can create our own default type that contains the behavior we want, handling our logic in an object oriented way rather than handling it imperitavly

    What's the point of that though? All it does is change null to something else, that's like completely deprecating the String class and replacing it with the ALL NEW SuperString class, which does exactly the same.. I don't see why null would have to be replaced if all it's going to be is a giant bitch.

    It allows our nulls to have behavior. Instead of needing an explicit condition (the null check) to specify the behavior that should go down, do it polymorphically, allowing us to completely get rid of null-checks. They aren't needed, a lot of developers (including myself) see it as noise, since it's a cheap way to achieve the logic you want (quick conditional statement to see if we should do nothing). You can achieve the same logic in an object oriented manner, allowing you to remove the need for the check. It allows your program to flow smoothly, without any un-needed conditonal checks
    Link to comment
    Share on other sites

    Which works if you have an empty array (I think) and empty strings etc. (I haven't really tested how deep None goes in a while, forgive me if I'm mistaken)

    But personally, I like null. It's more of a personal thing though, as I like to be 100% sure that something doesn't exist.

    That and if there isn't a consistent use of what is/isn't "existing" (empty arrays, empty strings rather than just null) then soon if statements from methods end up being

    String a = yourMethodThing();

    if(a == null || a.equals("") || a.equals("null"))

     

    Thus adding more areas of "what could go wrong?" and ending up with duplicate, unnecessary code.

     

    I did enjoy reading this (I'll be honest, I skimmed a lot of it because I'm trying to get motivated to do homework and don't have time to really read it), and will probably reread it again later. (inb4 I'm completely off on what I'm talking about and now I look like a fool)

     

    Thanks for posting. :DThere are 2 reasons you would perform a null-check:

     

    1. To lazily initialize a variable (variables that are only initialized when first used; saves memory)

     

    2. To do nothing (if it's null, it's empty and we dont wanna do anything for the empty value; do nothing)

     

    Creating a new conditional statement to "do nothing if there's no value" is pretty tedious, especially if you're using a variable that might contain null in many different places. 

     

    Instead, if a default value was used, which had the behavior of doing nothing, you could remove the need for null-checks.

     

    To give an example, lets say you were putting animals into cages. You have a cage and you have an animal.

     

     

    Cage cage = new Cage();
    Animal[] animals = {
         new Dog(),
         new Cat(),
         null,
         new Dog();
    };
    Our array has 1 empty variable (null). Since there is a null in there, we must perform a null-check to prevent NullPointerExceptions:

     

    for(Animal animal : animals) {
        if(animal != null)
            animal.putInCage(cage);
    }
    Easy enough. But if we instead replaced null with our own default value, we could get the same effect without a null check:

     

    Animal[] animals = {
         new Dog(),
         new Cat(),
         new NoAnimal(),
         new Dog();
    };
    
    
    for(Animal animal : animals)
         animal.putInCage(cage);
     

    When the NoAnimal instance is used, nothing happens (like we wanted) since the putInCage method for NoAnimal does nothing (as shown below). This gives us the same logic that we wanted, without the need for a null-check.

    abstract class Animal {
         public abstract void putInCage(Cage cage);
    }
    
    
    class Dog extends Animal {
         public void putInCage(Cage cage) {
              System.out.println("The dog whimpes as it goes in the cage");
         }
    }
    
    
    class Cat extends Animal {
         public void putInCage(Cage cage) {
              System.out.println("The cat hisses as it goes in the cage");
         }
    }
    
    
    class NoAnimal extends Animal {
         public void putInCage(Cage cage) {
              //does nothing
         }
    }
    You actually don't; check out my example. The check is not needed since we already know we want to "do nothing" (or perform some other default behavior). Since we already know that, we can create our own default type that contains the behavior we want, handling our logic in an object oriented way rather than handling it imperitavly

     

    It allows our nulls to have behavior. Instead of needing an explicit condition (the null check) to specify the behavior that should go down, do it polymorphically, allowing us to completely get rid of null-checks. They aren't needed, a lot of developers (including myself) see it as noise, since it's a cheap way to achieve the logic you want (quick conditional statement to see if we should do nothing). You can achieve the same logic in an object oriented manner, allowing you to remove the need for the check. It allows your program to flow smoothly, without any un-needed conditonal checks

     

    you could just put it in a try catch block and just use a method on null kek

    Link to comment
    Share on other sites

    you could just put it in a try catch block and just use a method on null kek

    Not sure what you mean by that. If you're saying "catch the NullPointerException", wouldnt an if-else be a lot cleaner? The point of this is to remove null as a value, since it has no behavior, thus removing the need to check for it. Personally, I feel (lightweight) implicit default instances would be a lot cleaner than null-checks. Also, if your variable switches between null and an actual value quite often, you wouldn't get any benifits from runtime optimizations. We are optimizing out the conditional statement manually at source level
    Link to comment
    Share on other sites

    Lol, this is just null and you talking about it like its the majority of everything XD

     

    It cannot be applied for every design sometimes its just waste of implementation what if you have hierarchy of dozen classes that can hold null's would you create emtpy object for every of em? I dont think so.

     

    You also frogot that method invocation is hella slower than jumping to another branch.

    This could be applied for small chunks of code but i personally dont see huge usage of it, maybe because im C child.

    Link to comment
    Share on other sites

    Anyone that doesn't think nulls are valuable to a language either is a moron or has never worked on a business application in their entire life. There's countless times where you need to represent nothing, a null provides that. One of the biggest issues I have with Java is that the primitives aren't nullable.

    Link to comment
    Share on other sites

    Lol, this is just null and you talking about it like its the majority of everything XD

     

    It cannot be applied for every design sometimes its just waste of implementation what if you have hierarchy of dozen classes that can hold null's would you create emtpy object for every of em? I dont think so.

     

    You also frogot that method invocation is hella slower than jumping to another branch.

    This could be applied for small chunks of code but i personally dont see huge usage of it, maybe because im C child.

    Branching using conditionals doesn't give room for runtime optimizations like on stack replacement. But seeing how you mention you're a C child, I can totally understand, seeing how such optimizations don't exist there, and branching WOULD be the best way to go. As for Java, you can perform the benchmarks yourself if you wanted. Conditionals are alright in situations where the condition remains the same for extended periods. But for large-scale projects, not only would if-else statements clutter up a class, but as stated before, there is little to be done for conditionals when it comes to runtime optimizations. Although the techniques I may have mentioned above apply strictly to Java, any language which supports managed code is a canidate for adding such optimizations.

    Anyone that doesn't think nulls are valuable to a language either is a moron or has never worked on a business application in their entire life. There's countless times where you need to represent nothing, a null provides that. One of the biggest issues I have with Java is that the primitives aren't nullable.

    Coming from the kid who always tries to say I'm wrong, yet gets the truth shoved down his little ameture throat every time. I'm getting sick of your disrespectful attitude (how you bash on OSBot yet go on there every day; how you down anyone who might seem a little less knowledgable than you).

     

    If null is so valuable, how about you stop talking shit and start giving reasons? Oh, and do your research first, cause based off previous encounters with you, I have yet to see you show any effort towards looking into things before speaking.. Try to give me one example where null is useful, and I'll gladly show you how it's not and can be replaced with a better behavior system. You want null just so you can check it? Come on now, the real goal is to execute code based on whether there's a value or not. If you used your own default "no value" value, you could contain the bahvior you want in it and execute it without any "null-check". It's the same logic without the check

    Link to comment
    Share on other sites

    Coming from the kid who always tries to say I'm wrong, yet gets the truth shoved down his little ameture throat every time. I'm getting sick of your disrespectful attitude (how you bash on OSBot yet go on there every day; how you down anyone who might seem a little less knowledgable than you).

     

    If null is so valuable, how about you stop talking shit and start giving reasons?

    OSBots owned by a lazy kid who laughs his way to the bank and a scamming admin who's banned on all other sites (should be OSBot as well since he's scammed there to). Please tell me why you would ever want to even be slightly interested in the site besides as a place to troll when you're bored.

     

    As for nulls, goodluck representing a value of nothing (did a user check a checkbox, leave it blank or miss it completely (find dirty data)?). You provide incredibly retarded answers (create an empty object to compare instead of null wtf?) and then go on to ask me for reasons. Maybe you should apply your knowledge (which is a hella lot more than mine) to actually building something instead of being a textbook kid with no experience.

    Link to comment
    Share on other sites

    OSBots owned by a lazy kid who laughs his way to the bank and a scamming admin who's banned on all other sites (should be OSBot as well since he's scammed there to). Please tell me why you would ever want to even be slightly interested in the site besides as a place to troll when you're bored.

     

    As for nulls, goodluck representing a value of nothing (did a user check a checkbox, leave it blank or miss it completely (find dirty data)?). You provide incredibly retarded answers (create an empty object to compare instead of null wtf?) and then go on to ask me for reasons. Maybe you should apply your knowledge (which is a hella lot more than mine) to actually building something instead of being a textbook kid with no experience.

    If a user didnt check a box, the NotChecked would be returnes instead of null. There's no luck; it's pure logic. When you check for null, you perform something afterwards, based on whether there is a value or not. Instead of having to check if it's empty, we already know it's empty cause it has an empty value. We can then use that empty value to either do nothing or perform a default task, rather than get a NPE (which ia why we need the tedious check). Maybe if you trolled less amd studied more, this would make sense to you.

     

    If you took the time to read, you'll see that no comparing is going down. I removed the need to compare (against null or anything else). Read it again...

     

    As for experience, I have plenty, so no need to worry about that. If I didn't have experience, I wouldn't come across such situations that motivate me to look into topics like this.

    Link to comment
    Share on other sites

    There are 2 reasons you would perform a null-check:

     

    You actually don't; check out my example. The check is not needed since we already know we want to "do nothing" (or perform some other default behavior). Since we already know that, we can create our own default type that contains the behavior we want, handling our logic in an object oriented way rather than handling it imperitavly

    It allows our nulls to have behavior. Instead of needing an explicit condition (the null check) to specify the behavior that should go down, do it polymorphically, allowing us to completely get rid of null-checks. They aren't needed, a lot of developers (including myself) see it as noise, since it's a cheap way to achieve the logic you want (quick conditional statement to see if we should do nothing). You can achieve the same logic in an object oriented manner, allowing you to remove the need for the check. It allows your program to flow smoothly, without any un-needed conditonal checks

    That is a rather exhausting example to this simple problem. If it was really necessary to get rid of null checks, the jvm would "do nothing" when trying to access a method on a null object. Instead of creating a "No" object for every type of object you have. Obviously you can see everyone has different thoughts and opinions on the subject. Because of that, no answer is right. I'm not right, you're not right. We all program in different ways, as we're all creatures of habit. Just because you think it's useless doesn't mean it is. You should post a larger project you've written which has no null checks. Could be fun to see how you do your thing!

     

    Personally, most of my simulation projects involve no null checks; however, they're all very straight forward and there will never be a null case. For monopoly, bingo and blackjack at least (I gamble some times)

    If a user didnt check a box, the NotChecked would be returnes instead of null.

    uhhhh..

     

    boolean checked = false;
    
    Link to comment
    Share on other sites

    If a user didnt check a box, the NotChecked would be returnes instead of null. There's no luck; it's pure logic. When you check for null, you perform something afterwards, based on whether there is a value or not. Instead of having to check if it's empty, we already know it's empty cause it has an empty value. We can then use that empty value to either do nothing or perform a default task, rather than get a NPE (which ia why we need the tedious check). Maybe if you trolled less amd studied more, this would make sense to you.

     

    If you took the time to read, you'll see that no comparing is going down. I removed the need to compare (against null or anything else). Read it again...

     

    As for experience, I have plenty, so no need to worry about that. If I didn't have experience, I wouldn't come across such situations that motivate me to look into topics like this.

    I recommend that you read up on the basics. http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

    Link to comment
    Share on other sites

    Archived

    This topic is now archived and is closed to further replies.

    ×
    ×
    • Create New...

    Important Information

    We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.