=== null vs. == null

[jazzman1]

She want's to be maybe:

<?php

function myFunc($arg1, $arg2=NULL){
   if($arg2 == NULL){
      $arg2 = array('Some other data', $arg1, 'more data');
   }

   return $arg2;
}

echo '<pre>'.print_r(myFunc(1)).'</pre>'; 

[btherl]

nevermind, early php, only had concept of null to address DB access, and using php to retrieve said values, and now php is all nullified!

 

now me pissing and lol.

 

$var;  actually declaring a var is not necessary in loosely typed php, initializing is good enuff.  A php trait.

 

regardless of PHP implementation, comparing nulls should be an exception(doh!), not common coding practice.

 

Comparing against null with its traditional meaning from SQL is asking "Is this variable unknown?".  It's a sensible question to ask, and routine when doing left joins.  Being unknown is information, and sometimes we need to know the difference between "unknown" and "known", or "unknown" and "doesn't exist".

 

If we carry the same meaning over to php, it still makes sense to compare against null when asking if a variable has an unknown value.  It's true that it's often used to mean "undefined", like perl's "undef", but that's because of how PHP treats undefined variables.  Programmers are just following PHP when they do that.

[kicken]

Ah good.

Well it still seems like NULL has a good purpose there then. It's something you don't allow the argument to be.

*shrug*

 

I use null for function defaults if there's not something more appropriate as I feel it is more semantically correct.  Null represents and unknown value and if someone does not pass an argument to a function then it's value is unknown as it was never specified. In the function body I'll test for that unknown state and handle it appropriately.  Sometimes that means trying to calculate/guess the correct value, sometimes it means skipping a particular block of code, sometimes it means other things.

 

[Psycho]

OK, this is splitting hairs and is really diving into the depths of semantics. But, I have to respond regarding the last two posts on what NULL represents. NULL does not, necessarily, represent an "unknown" value. It was originally used to represents a value that does not exist. An unknown value infers that there is a value or at least there could be a value. NULL is the absence of a value. In other words, it is known that there is no value. That is how I have always conceptualized NULL.

 

If you look at the results I posted on the previous page isnull($var) and $var === NULL only return true when the value or $var is explicitly set to NULL or $var has not been set. Even if $var is set to an empty string it is not considered NULL because an empty string is a value.

 

Let's just be glad that the concept of two different NULL types has never been implemented.

[btherl]

I'll continue splitting hairs .  In SQL null was intended to represent "unknown" specifically.  It's different from what it means in a programming language.  That's why it has these semantics:

 

x > null : false (x might be smaller..)

x < null : false (x might be larger..)

x = null : false (x might not be equal)

x != null : false (x might be equal)

 

It's the last one that is surprising - if null meant "no value", you would expect everything to be not equal to null.  But because it means "unknown", and we don't know if x is not equal to an unknown value, the comparison is false.

 

It's different in a programming language, where null means "no value" and x != null is true because x has a value and null doesn't.  In php you have to do x !== null to get these semantics, which is an unfortunate design choice IMHO.  Strict comparison should be the default.

 

Of course in practice most people use null for "no value" in sql anyway.. and we've all learnt to work around sql's assumption that null means unknown, like using the "is distinct from" operator - it's just like "!=" except it treats null as not equal to any known value.

[scootstah]

which is an unfortunate design choice IMHO.  Strict comparison should be the default.

 

I disagree. PHP was not meant to be a strictly typed language, and a lot of things wouldn't work in their current state if it was. There are many other languages that follow suit.

 

I don't think it is a huge deal. As long as you understand the difference between == and ===, you shouldn't ever have any problems.

[ManiacDan]

which is an unfortunate design choice IMHO.  Strict comparison should be the default.

 

I disagree. PHP was not meant to be a strictly typed language, and a lot of things wouldn't work in their current state if it was. There are many other languages that follow suit.

 

I don't think it is a huge deal. As long as you understand the difference between == and ===, you shouldn't ever have any problems.

I'm with you.  Most of the complaints about PHP stem from either (a) not understanding loosely typed languages or (b) not understanding symbol tables.  PHP is loosely typed.  == is not ===.  If you really really care about data types (like in this specific scenario), use ===.  Otherwise, == is magical.  Empty strings, zero, negative one, false, empty objects, empty arrays, whatever.  "not something" a very powerful concept.

[Psycho]

I'll continue splitting hairs .  In SQL null was intended to represent "unknown" specifically.

 

Well, yes and no. It does not specifically mean "unknown". It means "unknown" or "inapplicable" information - i.e. it does not exist. If I do a DB query on the parents table and JOIN it to the children table, a user with no children will have null values. If I do a COUNT() using GROUP BY for those children I get 0. If the result of the count was unknown I would get a null count. It can mean either or - which is why Codd had proposed using two different NULLs to differentiate the two.

 

Codd's rules:

Rule 3: Systematic treatment of null values:

 

The DBMS must allow each field to remain null (or empty). Specifically, it must support a representation of "missing information and inapplicable information" that is systematic, distinct from all regular values (for example, "distinct from zero or any other number", in the case of numeric values), and independent of data type. It is also implied that such representations must be manipulated by the DBMS in a systematic way.

[btherl]

I'll continue splitting hairs .  In SQL null was intended to represent "unknown" specifically.

 

Well, yes and no. It does not specifically mean "unknown". It means "unknown" or "inapplicable" information - i.e. it does not exist. If I do a DB query on the parents table and JOIN it to the children table, a user with no children will have null values. If I do a COUNT() using GROUP BY for those children I get 0. If the result of the count was unknown I would get a null count. It can mean either or - which is why Codd had proposed using two different NULLs to differentiate the two.

 

Codd's rules:

Rule 3: Systematic treatment of null values:

 

The DBMS must allow each field to remain null (or empty). Specifically, it must support a representation of "missing information and inapplicable information" that is systematic, distinct from all regular values (for example, "distinct from zero or any other number", in the case of numeric values), and independent of data type. It is also implied that such representations must be manipulated by the DBMS in a systematic way.

 

Thankyou, that's quite interesting.. I tried it and it works just like you said.  I never count columns, only count(*), so I hadn't noticed.

[Mahngiel]

NULL does not, necessarily, represent an "unknown" value. It was originally used to represents a value that does not exist. An unknown value infers that there is a value or at least there could be a value. NULL is the absence of a value. In other words, it is known that there is no value. That is how I have always conceptualized NULL.

 

Yes, yes, i really like and agree with this.