SitePoint Sponsor

User Tag List

Results 1 to 12 of 12
  1. #1
    SitePoint Evangelist hessodreamy's Avatar
    Join Date
    Apr 2005
    Location
    uk
    Posts
    518
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)

    Differentiating between defined class properties being NULL and not set?

    Say if I declare a bunch of class properties in my class definition but do not assign them values, how can I later on tell whether they have been set? The values are null by default so how can I know whether they've been set as null, rather than not being set?
    eg
    Code:
    class SomeClass
    {
    	public $myVar;
    }
    
    $someObject = new SomeClass();
    var_dump(is_null($someObject->myVar));// this is true because it's null by default
    
    $someObject->myVar = null;
    var_dump(is_null($someObject->myVar));// this is true because it's is set it to null!

  2. #2
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Why does it matter? The value is null, work with that not whether it has been set or not.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  3. #3
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    4,807
    Mentioned
    141 Post(s)
    Tagged
    0 Thread(s)
    I suspect she/he might be asking because null could be a valid value for the property of her/his object. So you can't tell if it was just instantiated or if the user actually provided a value for the property (be it a value of null).

    I do however, agree with you @logic_earth, in that you should treat null as not set. Same issue exists in other languages. What we do instead is track changes to the property, not whether or not their are instantiated or not. So the workflow is, load the object from your data store, persist its state (include property state), as the user makes changes, check if the update value differs from the objects prior state, mark the object as dirty (meaning changed) and store the new value.

  4. #4
    SitePoint Evangelist hessodreamy's Avatar
    Join Date
    Apr 2005
    Location
    uk
    Posts
    518
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    The reason for the question is that I'm defining a bunch of getter methods for a class that will check if the property has been set and, if it has not, grab it from the database (I'm trying to be efficient with database calls), and set the property. In either case it then returns the value.
    eg
    Code:
    function getValue()
    {
    	if(is_null($this->value))
    	{
    		$this->value = $this->getValueFromDatabase("value");
    	}
    	return $this->value;
    }
    As cpradio says, the value taken from the database could well be a null, in which case the database would be accessed every time.

    I get the gist that testing is_null and isset on the property itself isn't going to help me. I get what you're saying about marking the property as changed. Maybe something like this?
    Code:
    function getValue()
    {
    	if(! property_exists($this, "db_value"))
    	{
    		$this->value = $this->getValueFromDatabase("value");
    		$this->db_value=true; //registers that we've got this value from the db
    	}
    	return $this->value;
    }

  5. #5
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    988
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    I'm not sure there's an answer to your question, however, querying the database for each individual value is going to be more of a performance issue than loading the entire record the first time a single value is needed.

  6. #6
    SitePoint Evangelist hessodreamy's Avatar
    Join Date
    Apr 2005
    Location
    uk
    Posts
    518
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    I'm not sure there's an answer to your question, however, querying the database for each individual value is going to be more of a performance issue than loading the entire record the first time a single value is needed.
    Oh sure, the database access is going to be pulling in all values. I left that part out for the sake of simplicity.

  7. #7
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    988
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Then I think the simplest solution is to add a private field which is a boolean that stores whether the record has been fetched for not.

  8. #8
    SitePoint Evangelist hessodreamy's Avatar
    Join Date
    Apr 2005
    Location
    uk
    Posts
    518
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    Then I think the simplest solution is to add a private field which is a boolean that stores whether the record has been fetched for not.
    Yeah, that sounds like the way to go. Cheers.

  9. #9
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    I'm confused...why does it need to fetch the value of a single property from the database if it already got it from the database with the initial query?
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  10. #10
    SitePoint Evangelist hessodreamy's Avatar
    Join Date
    Apr 2005
    Location
    uk
    Posts
    518
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    I'm confused...why does it need to fetch the value of a single property from the database if it already got it from the database with the initial query?
    Well it was kinda beyond the scope of what I was asking, but the class I'm doing will have many uses, be extended extensively, and may have a lot of properties. Some of the properties might be more database intensive and less frequently used, so didn't want to load everything by default. So the easily-reached properties will be loaded in the constructor, and other properties that might require heavier database work can be grabbed from the database when required, but only once. I'm also allowing the possibility that properties may or may not have been loaded in the constructor. I'm covering a lot of possibilities here.

  11. #11
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    If a set of properties require more work then the others, you would probably be better off giving them their own object...otherwise...I don't know...to me it sounds like, trying to fix a performance issue before there is a performance issue with incomplete data. Akin to micro-optimization. Have you profiled and assessed your concerns are correct?

    There are always better ways...that don't seem so "hacky" if you want to cal it that.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  12. #12
    SitePoint Evangelist hessodreamy's Avatar
    Join Date
    Apr 2005
    Location
    uk
    Posts
    518
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    If a set of properties require more work then the others, you would probably be better off giving them their own object...otherwise...I don't know...
    That's something I will consider, yes.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •