• Kenneth (unregistered) in reply to Yankee Doodle
    Yankee Doodle:
    What's with all this internationalization anyway? Didn't anyone stop to think what a pain that would be? The Bible is written in English. 26 letters ought to be enough for anyone.

    Sorry - the Bible was NOT written in English... It was written in Hebrew (I think?).

  • Ronnie Corbett (unregistered) in reply to Kenneth
    Kenneth:
    Yankee Doodle:
    What's with all this internationalization anyway? Didn't anyone stop to think what a pain that would be? The Bible is written in English. 26 letters ought to be enough for anyone.

    Sorry - the Bible was NOT written in English... It was written in Hebrew (I think?).

    No No. English is a language. Hebrew is a male teabag.

  • (cs) in reply to boh
    boh:
    Airhead:
    frits:
    "Hi. I can't find Mikael Åkerfeldt's name in your address book."
    Yeah, we don't care about accents, so it's listed under A.
    Except it isn't an accent - it's letter #27 in the Swedish alphabet.

    Or letter #26, if you take in the fact that 'v' and 'w' are basically the same letter in swedish, only spelled differently.

    See, we Americans have letters that sound the same some of the time, but (at least barring some arguments regarding w/u and y/e) we make most of them do extra work so that none of them completely overlap. So we don't get this lovely concept of spelling a letter differently very often.

  • (cs) in reply to Kenneth
    Kenneth:
    Yankee Doodle:
    What's with all this internationalization anyway? Didn't anyone stop to think what a pain that would be? The Bible is written in English. 26 letters ought to be enough for anyone.

    Sorry - the Bible was NOT written in English... It was written in Hebrew (I think?).

    1.) It was clearly a joke 2.) The Old Testament was written primarily in Hebrew with a couple small sections in Aramaic. The New Testament was written in Greek although parts are also duplicated in Hebrew and Aramaic as well

  • (cs)

    I'm surprised no one else has mentioned this: the $output variable is not set prior to the if block that evaluates whether $list is an array. Which means if something called this function and fed it a variable that was not a list, it would return "Undefined variable error".

    Not that it's the biggest WTF in the function, but if you don't know enough to initialize variables before you assign things to them, you probably should not be allowed to program anything to start with.

  • (cs) in reply to CaptainSmartass
    CaptainSmartass:
    I'm surprised no one else has mentioned this: the $output variable is not set prior to the if block that evaluates whether $list is an array. Which means if something called this function and fed it a variable that was not a list, it would return "Undefined variable error".
    Sorry Captain, but if something called this function and fed it a variable that was not a list, it would skip that IF block, and go right on to the next, which does set the $output variable. There would be no such error.
  • qbolec (unregistered) in reply to boog
    boog:
    CaptainSmartass:
    I'm surprised no one else has mentioned this: the $output variable is not set prior to the if block that evaluates whether $list is an array. Which means if something called this function and fed it a variable that was not a list, it would return "Undefined variable error".
    Sorry Captain, but if something called this function and fed it a variable that was not a list, it would skip that IF block, and go right on to the next, which does set the $output variable. There would be no such error.
    unless he meant empty alphabet, which is quite interesting case
  • Jonathan (unregistered)

    Um, guys? If you don't need the HAVING then you don't need the COUNT either:

    SELECT DISTINCT SUBSTR(last_name, 1, 1) FROM customers

  • Jonathan (unregistered) in reply to Jonathan

    This all assumes the address book isn't stored in a text file, of course.

  • K (unregistered) in reply to Yankee Doodle
    Yankee Doodle:
    The Bible is written in English.
    I cannot figure out if this a troll, a joke, or if you really believe it. But assuming it is a joke, I can see the humor.
  • (cs) in reply to Jonathan
    Jonathan:
    Um, guys? If you don't need the HAVING then you don't need the COUNT either:

    SELECT DISTINCT SUBSTR(last_name, 1, 1) FROM customers

    At least the COUNT does something. Your version provides less information than the original.
  • Duracell (unregistered) in reply to frits
    frits:
    "Hi. I can't find Mikael Åkerfeldt's name in your address book."

    An Opeth reference on TDWTF? Awesome!

  • jumentum (unregistered) in reply to Airhead
    Airhead:
    frits:
    "Hi. I can't find Mikael Åkerfeldt's name in your address book."
    Yeah, we don't care about accents, so it's listed under A.

    Your software doesn't meet the legal requirements where I live, but thanks for your offer anyway. Don't call us, we'll call you.

  • refoveo (unregistered) in reply to trwtf
    trwtf:
    Anybody who has trouble sorting ch as a single letter needs to sit down and have a long, hard think about what it is they're doing in this business.

    Seconded. Apart from ch in swedish and Spanish, there's

    ij in Dutch (?) ll, rh and a few others in Welsh

    Also last names starting with St and Sch had their own sections in German filing cabinets in the previous century. Paper address books still have separate pages because there are so many last names with S that separating St and Sch really helps.

  • Paul (unregistered) in reply to Jonathan
    Jonathan:
    Um, guys? If you don't need the HAVING then you don't need the COUNT either:

    SELECT DISTINCT SUBSTR(last_name, 1, 1) FROM customers

    But wouldn't this need a full scan through the database anyway?

    OK, that'd be quicker than getting the whole data result set, and THEN going through it again, but wouldn't you be better either:

    • have a computed index on "substr(last_name,1,1)" (assuming the DB supports computed indices)

    or

    SELECT SUBSTR(last_name, 1, 1) FROM customers WHERE last_name like 'A%' UNION SELECT SUBSTR(last_name, 1, 1) FROM customers WHERE last_name like 'B%' etc

    (if the database can optimize "LIKE 'A%'" to use an index)

    or

    SELECT SUBSTR(last_name, 1, 1) FROM customers WHERE last_name >='A' AND last_name <'B' UNION SELECT SUBSTR(last_name, 1, 1) FROM customers WHERE last_name >='B' AND last_name <'C' etc

    (if the database can't optimize "LIKE 'A%'")

    That way, it needs to do 26 navigations of the index tree to find the results, rather than a full scan of the whole data set. Of course, which of these is quicker would depend on lots of variables - probably need load testing.

    But - doing it the original way was just dumb - if nothing else you're having to get the full data set from the database, just for this.

    (If it was THAT important to do this, I think I'd probably use a separate letter/count table, with triggers to keep it updated)

  • The Other Man (unregistered) in reply to Jon
    Jon:
    Article:
    My clients (all two of them) assign me low-priority, get-it-done-whenever type projects...

    Want, want, want!

    To clarify, you want two clients who give you such an unimportant (i.e. inexpensive) workload that they don't care when it gets done? That kinda sucks; there's a reason this guy has a day job.

  • (cs) in reply to Paul
    Paul:
    Jonathan:
    Um, guys? If you don't need the HAVING then you don't need the COUNT either:

    SELECT DISTINCT SUBSTR(last_name, 1, 1) FROM customers

    But wouldn't this need a full scan through the database anyway?

    OK, that'd be quicker than getting the whole data result set, and THEN going through it again, but wouldn't you be better either:

    • have a computed index on "substr(last_name,1,1)" (assuming the DB supports computed indices)

    or

    SELECT SUBSTR(last_name, 1, 1) FROM customers WHERE last_name like 'A%' UNION SELECT SUBSTR(last_name, 1, 1) FROM customers WHERE last_name like 'B%' etc

    (if the database can optimize "LIKE 'A%'" to use an index)

    or

    SELECT SUBSTR(last_name, 1, 1) FROM customers WHERE last_name >='A' AND last_name <'B' UNION SELECT SUBSTR(last_name, 1, 1) FROM customers WHERE last_name >='B' AND last_name <'C' etc

    (if the database can't optimize "LIKE 'A%'")

    That way, it needs to do 26 navigations of the index tree to find the results, rather than a full scan of the whole data set. Of course, which of these is quicker would depend on lots of variables - probably need load testing.

    But - doing it the original way was just dumb - if nothing else you're having to get the full data set from the database, just for this.

    (If it was THAT important to do this, I think I'd probably use a separate letter/count table, with triggers to keep it updated)

    SELECT ISNULL((SELECT 1 WHERE EXISTS (SELECT 1 FROM Customers WHERE last_name LIKE 'A%')), 0)

    This will run pretty much instantly if there is an index on last_name, and requires no trigger to keep a letter count table updated. Locking on the letter table will probably be a performance killer if the customer table is large enough for it to be worth making the letter table in the first place.

  • Kim (unregistered) in reply to frits

    He's listed under "Demon of the fall"

  • (cs) in reply to Design Pattern
    Design Pattern:
    ClaudeSuck.de:
    Jaime:
    ClaudeSuck.de:
    SELECT SUBSTR(LastName), Count(*) FROM Customers GROUP BY SUBSTR(LastName) HAVING Count(*) > 0 ORDER BY SUBSTR(LastName)
    Why include the HAVING clause? It's roughly equivalent to "WHERE 1=1", except more expensive to evaluate.
    The HAVING clause checks if this letter has a count bigger than zero, i.e. if this letter is not in the address book it will also not be in the resultset.
    In which alternat universe are you living?

    It must be one where the SELECT clause selects data that does not exist in the database!

    Well done.

  • B (unregistered) in reply to frits

    You'll have to explain the Opeth reference there..

  • (cs)

    I'm suprised nobody has pointed this out yet. What's really sad, is that the whole big $list array is not passed as a reference ( &$list ). That means PHP has made a copy of $list in memory before passing it to the function.

    function getAlphabetList($list = null)

    should be:

    function getAlphabetList(&$list = array())

    Never mind the other issues with the function, the problems begin with the function declaration.

  • illum (unregistered) in reply to refoveo
    refoveo:
    trwtf:
    Anybody who has trouble sorting ch as a single letter needs to sit down and have a long, hard think about what it is they're doing in this business.

    Seconded. Apart from ch in swedish and Spanish, ...

    ch in Swedish? What are you smoking?

  • Tony (unregistered)

    It's just a naive implementation. TRWTF is that they couldn't spot this and some network admin had to be brought in. I bet there are profilers for php available. Hell, they could just print to html page how much method calls took time.

Leave a comment on “Thorough Letter Checking”

Log In or post as a guest

Replying to comment #:

« Return to Article