• Dennis (unregistered)

    Isn't returning false when not finding anything pretty much the PHP standard? At least most search methods in the standard PHP API does so.

    I'd consider that the most correct implementation of search, given the language/platform.

  • my name is missing (unregistered)

    This comment has been unset.

  • (nodebb)

    Regardless of the wisdom or lack thereof of spelling "null" F-A-L-S-E, the unset call is redundant - $obj is a local (it's not declared global, ergo it's local), and is therefore unset automatically(1) when the function exits.

    (1) It's PHP, so I suspect the general rule of "It's PHP, who knows exactly what it will do?" is applicable.

  • Robin (unregistered)

    Much though I think PHP is totally broken, the only WTF in here seems to be that the same variable is unset twice. Which is certainly, er, interesting - but hardly a massive WTF imo.

    (I actually never knew unset took more than one argument - but it does actually seem sane to allow multiple variables to be passed in and have them all deleted. The semantics of a language having a function call where it matters precisely what variable is passed in, rather than just what value it has, is obviously less so, but I digress.)

    Oh, and on returning false if no match is found - it is correct that similar builtin functions do this, but that's just one of many really dumb things that PHP does. If you have a function that returns an index, the last thing you want on a failure to find it is to have a value that will silently coerce to the perfectly valid index of 0 whenever you try to use it! (You could argue that the real WTF here is the weak typing, and I can't massively disagree - except to point out that Javascript has similar, albeit not quite as bad, typing issues, but copes perfectly fine here by following the normal convention of returning -1 when it can't find an index.)

  • (nodebb) in reply to Robin

    The semantics of a language having a function call where it matters precisely what variable is passed in, rather than just what value it has, is obviously less so, but I digress.

    That would be because unset(...) might look like a function call, but isn't, in the same sort of way that (int) might look like a C-style cast operator, but isn't, because int isn't a thing in PHP.

    I would have had the syntax of unset be more like unset $something, $anotherthing, $yetathirdthing

  • (nodebb) in reply to Robin

    You could argue that the real WTF here is the weak typing, and I can't massively disagree

    I disagree. For sure it's a real WTF, but it isn't really "weak typing", but more "overenthusiastic type conversion".

  • (nodebb) in reply to Robin

    the same variable is unset twice

    Not exactly. Two different variables referencing the same underlying item are unset. The WTF is that one of those two variables is going to be unset anyway as soon as the function returns.

  • Robin (unregistered) in reply to Steve_The_Cynic

    That to me is what "weak typing" basically means. It's a different axis to static vs dynamic typing, although frequently confused with it. Languages like PHP and JS, with their willingness to silently convert types at the drop of a hat, are the archetypal "weakly typed" languages - in contrast to, for example, Python, which although dynamically typed, at least throws an error if you try to do various things which are nonsensical given the types involved. And then you have things like C which, although statically typed, I believe does automatic type conversions in a number of situations (disclaimer: I don't know C so I may well not have that quite right, but my understanding is that its type system is relatively "weak" in some sense).

  • (nodebb) in reply to Robin

    You're not wrong about C, although at least there the automatic conversions are numeric-to-numeric, and most compilers will, if not configured wrongly, warn you about the more dangerous ones (int=>char, long=>float, float=>long, etc.).

    But there are other things that can be called "weak typing", and I would include in that any language where typing of variables is flexible. That variable is an int because the last thing I stored there is an int, but if I store a string in there, now it's a string, and there will be no warning when that happens. It's at least somewhat reasonable to call that "weak typing", and it presents a different set of problems than "overenthusiastic type conversion".

    That said, the two often go hand-in-hand, so it might even be the two together which is "weak typing".

    For maximum fun on differences between languages, though, try this simple expression:

        "Hello world! "+4

    which has aggressively different behaviour between C/C++ ("o world! ") and JavaScript ("Hello world! 4") as a former colleague found out to his dismay.

  • MiserableOldGit (unregistered)

    Whilst it is obviously daft to get rid of $obj when it will go anyway, I can't see why it was created in the first place.

    Is this another example of a method that started out as one thing and has now been revised and updated into something different by someone too timid to tidy out the cruft?

    I'm curious, what would happen if we just called unset($this->_shipments[$key]); where $key was false ... ?

  • (nodebb) in reply to Steve_The_Cynic
    But there are other things that can be called "weak typing", and I would include in that any language where typing of variables is flexible. That variable is an int because the last thing I stored there is an int, but if I store a string in there, now it's a string, and there will be no warning when that happens. It's at least somewhat reasonable to call that "weak typing", and it presents a different set of problems than "overenthusiastic type conversion".

    I'm pretty sure that would be called dynamic typing, i.e. the type of the variable is whatever the type of the last value stored in it. Most statically typed languages are also strongly typed, and most dynamically typed languages are also weakly typed, but there are exceptions. As Robin said, Python is an example of a language that is dynamically and strongly typed (the type of a variable can change, but values generally aren't coerced).

  • (nodebb) in reply to MiserableOldGit

    I'm curious, what would happen if we just called unset($this->_shipments[$key]); where $key was false ... ?

    Easy enough to find out if you hop onto a REPL (e.g. https://repl.it). In short, the false would be coerced into a zero because of the context, so it would be just the same as if $key === 0.

  • (nodebb) in reply to MiserableOldGit

    Whilst it is obviously daft to get rid of $obj when it will go anyway, I can't see why it was created in the first place.

    My guess? The method was originally going to return the deleted shipment; that's a common enough idiom. But when they realised the method might be called with a key that didn't have a corresponding shipment they panicked. Or maybe, much as you suggest, that's what it originally did.

    Addendum 2020-11-17 00:40: Oh, and thumbs down for that I-wish-it-were-Python habit of prepending method names with '_'.

  • Meeeee (unregistered)

    The "return $this;" may be a smalltalk-ism. In Smalltalk this is just the default.

  • (nodebb) in reply to MiserableOldGit

    I can't see why it was created in the first place.

    Lots of programmers create one-use variables all the time. It can be understandable if it refers to a complex expression, so that you break up an even more complex expression into more understandable parts. That's obviously not the case here, but people have bad habits.

    What bugs me more are the people who feel it's necessary to assign a new local variable from a function parameter. There seems to be a common idea that it's a bad idea to use parameters directly, especially if you're going to reassign it. Maybe this is a legacy of Fortran, which passes all parameters by reference (there's an old story about changing the value of a constant, because it passed a reference to the location in the literal pool).

  • john (unregistered)

    Ug. Testing for not false.

  • I'm not a robot (unregistered) in reply to Barry Margolin 0
    There seems to be a common idea that it's a bad idea to use parameters directly, especially if you're going to reassign it.
    The argument (no pun intended) that I've seen for that is that leaving the parameter unmodified is useful for debugging.
  • Some Ed (unregistered) in reply to MiserableOldGit

    I've seen other code that was like this, back when it was new enough for me to ask the developer. In that case, he said he first tried to delete the thing by querying the value and then using unset to delete it, but that didn't work. So he tried invoking unset on the instruction to get the thing directly, and that did.

    No matter how much I tried talking to him about it, I couldn't get him to explain why he left the code that was doing nothing there, nor could I get him to understand why it might be better to not have that code.

    To be fair, this was the same Perl programmer who decided to design a website in PHP, which he didn't know at all at the time, because "Perl doesn't do web pages". The guy who chose to use PHP 3 when the PHP trend was upgrading to PHP 4, because PHP 3 was "tried and true". And the guy who said that all the performance problems with our new website were due to the fact that the development environment only had 1/4 the processing power and 1/4 the memory of the prod machines, and all of the issues we found with his algorithms were us just not understanding how PHP 3 worked. (We were also Perl programmers, to be fair.) At least we had already identified the biggest problems to fix when we went prod, so we were able to roll out fixes quickly when it turned out that we had more than 4 people trying to use our prod web server at the same time.

Leave a comment on “Unset-tled”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article