Lying lies and the ORMs that tell them



  • I'm currently working on a PHP (yes, I know) project built on symfony and the Doctrine ORM. In testing I noticed that a case which I was sure should be hit wasn't, so I had to do some digging.

    Doctrine takes config in YAML files and builds stub classes for the entities configured. In this particular case I had configured entity Foo to have an integer property bar. The database migration Doctrine generated correctly created an integer column in the Foo table, and the stub BaseFoo class claimed to have an integer getBar() method:

     @method integer        getBar()             Returns the current record's "bar" value

    But for some reason, myFoo->getBar() === $expectedBar was failing. Logging indicated that it had the correct value, so I turned to PHP's is_int function. Nope. It turns out that getBar() returns a string, and the autogenerated documentation is as honest as GLaDOS.



  • They don't put those quotes around bar for no reason in: Returns the current record's "bar" value. It's stating plain and clear that it's a string! Does it have to put the dollar sign in front of it to be clearer? Like this?

    Returns the current record's "$bar" value



  • I haven't done much of anything useful with PHP, but if the === operator is anything like it is in Javascript, it would be testing reference equality, and not value equality. Though to be honest I'm not sure if Javascript would care about the distinction when using primitive types... let's open a Javascript interpreter and find out!


    [code]
    var x = 5;
    x === 5;
    [/code]


    Prints true... oh well, so much for that theory! 😛



  • @ekolis said:

    I haven't done much of anything useful with PHP, but if the === operator is anything like it is in Javascript, it would be testing reference equality, and not value equality. Though to be honest I'm not sure if Javascript would care about the distinction when using primitive types... let's open a Javascript interpreter and find out!


    <font size="2" face="Lucida Console">
    var x = 5;
    x === 5;
    </font>


    Prints true... oh well, so much for that theory! 😛
     

    In JavaScript and PHP, === forces the language to not do type coercion.  "5" == 5 is true, "5"  === 5 is false.



  • @The poop of DOOM said:

    They don't put those quotes around bar for no reason in: Returns the current record's "bar" value. It's stating plain and clear that it's a string! Does it have to put the dollar sign in front of it to be clearer? Like this?

    Returns the current record's "$bar" value

    You do see the "@method integer" part, don't you?



  • @pjt33 said:

    the autogenerated documentation is as honest as GLaDOS.

    GLaDOS was honest. (eventually)



  • @ekolis said:

    if the === operator is anything like it is in Javascript, it would be testing reference equality, and not value equality.
     

    Javascript does not do reference equality explicitly, but if two variables point to the same object, then they're equal.

    a === b is shorthand for (a == b && typeof a == typeof b)

    a !== b is shorthand for (a != b && typeof a == typeof b)



  • @dhromed said:

    a !== b is shorthand for !(a === b), which is the same as (a != b || typeof a != b)
    FTFY.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.