Really short one here

By

February 3, 2013Uncategorized9 Comments

Trying to convert a small Java project to PHP, and got stuck immediately.

Common guys, really – how do you PHP people survive without a strict typesafe enum?!

I know PHP ppl don’t like strong typing, and you also can survive without method overloading, but this is… common ppl… no workaround for enum, NOTHING AT ALL?

I’ve been a Brainbench certified PHP master back in the year 2000. PHP sucked back then so I switched to C++ and Java. I kinda heard a rumor that PHP got somewhat better and even introduced minimal support for OOP.
Well, I can do some OOP in plain old ANSI C when I need to. I can work around missing OOP features if language is OOP unfriendly. I can understand why PHP has NO support for non-primitive const members. But as soon as I saw PHP suggestions for enum, I kinda stopped respecting PHP.

PHP sucks. Plain and simply, as a programming language, it just SUCKS.

9 Responses to “Really short one here”
  1. slicklash

    enums are considered as codesmell, you can always use constants. For non-primitive constants you should use statics.

    PHP is broken by design: http://wiki.theory.org/YourLanguageSucks#PHP_sucks_because:

    Anyway, don’t like it, don’t use it. Language related discussions are total waste of time.

  2. gugit

    > enums are considered as codesmell, you can always use constants.

    Eh?

    A method must be able to manifest what particular subset of constants it allows, and interpreter must enforce correct paramtype. That’s what enums are all about: helps protecting careless users from using a wrong constant.

    Consider:
    function Resource::open(Resource::OpenMode mode)
    to
    function Resource::open(int mode)

    I bet roughly 1 in 100 users will be open()ing the Resource with Resource::READ_ONLY instead of Resource::OPEN_MODE_READ_ONLY. Just because compiler/interpreter allows doing that.

    > Language related discussions are total waste of time.

    A honest statement that some wannabe “enterprise-level” language doesn’t support standard OOP features is just like a honest statement that some wannabe “reliable” vehicle manufacturer doesn’t care about accident rate. It’s all about making an informed choice.

    • slicklash

      > Eh?

      enums encourage the use of switch/if statements around all the code base. [Martin Fowler et. al, in Refactoring on “Switch statements”].
      What breaks DRY principle and is considered a code smell.

      Well, PHP is both dynamic and weak typed language. It’s naive to expect it to be like static typed one.

      • gugit

        Switch/if statements are just as common for enums as it is for constants, right? So a code with switch statements smells equally bad whether you use enums or constants. Sorry, cannot accept this explanation for a valid argument.

        Either way, in that particular algorithm I used mapping of [enum => handler], i.e. I used a hashmap instead of a switch statement. Which is not a smelly code as far as I’m aware.

        I admit PHP is a weakly typed language, but it still does have a type hinting feature. Which should be a perfectly sufficient method resolution mechanism (I mean, it’s all you need to have a method overloading).

        • gugit

          Update:

          as for “smelly code” and switches vs hashmaps: in a way both switch statements and hashmaps are suspicious by default. You need really good reason to use it.

          In my particular case, I was coding a custom client/server protocol. Either part reads a stream, recognizes keywords in it, and invokes a context-specific handler to process the command. And sorry, I do not know any better way for protocol implementation as using switch statements or hashmaps.

          • slicklash

            >Switch/if statements are just as common for enums as it is
            >for constants, right? So a code with switch statements
            >smells equally bad whether you use enums or constants.
            >Sorry, cannot accept this explanation for a valid argument.

            True, if you use constants as “type codes”, otherwise they are just labels for the *magic values*.

            I might have not clearly expressed myself. The enums and constants as type codes are encouraging _overuse_ of switch statements which by OOP evangelists is considered as a code smell.

            It doesn’t mean you shouldn’t use switch at all, you only need to be careful. Per-type switch should happen once and in only one class (mostly in factories). In case you have switch on same type code in different class that means the code is not so object-oriented after all. If one introduces new type code and does not update all switches and cover them in unit-tests someone else will run into “that should have never happened” issue. And when developer fights against introduction of new type code it is likely that code quality is poor.

            In your particular case enum will serve well in method declaration only. It does not protect from new type code introduction and hashtable based selective choice is no different from switch statement without “default” clause.
            Rising of not supported exception for unknown type code should be present.

            I am just assuming that you are doing explicit map (enum => handler), for that reason it’s inefficient and redundant to introduce an additional data structure since the set of handlers is finite. The normal switch statement should work better. In case you are reusing same handler static class or thread-safe singleton should serve well too.

  3. gugit

    > It doesn’t mean you shouldn’t use switch at all, you only need to be careful.

    No flames about it, bro :-)

    > hashtable based selective choice is no different from switch
    > statement without “default” clause.

    Disagree here though.

    Switch statements are static in a way that you cannot dynamically add/remove conditions or handlers. By using the hashmaps it’s easy to customize event handling at runtime. That’s why non-trivial communication protocols are better implemented by using hashmaps than switch statements.

    As for “default” clause, if you don’t find a registered handler in your map, you invoke the default one.

    As for enums, these things are unbelievably helpful for limiting user’s freedom of exceeding the allowed constant range.

    sendHandshake(HandshakeType type) is so much safer than sendHandshake(int type) and is so much easier to use than sendXYZHandshake().

    While at the receiving end, invokeHandler ( findHandler ( parseToken( instream) ) ) is so much more flexible than switch ( parseToken ( instream ) ){….}.

    The first idiom (quite trivial one) cannot be conveniently expressed in PHP. Because it is still not a mature language. Despite it’s hype and pump. Which is a long way of saying “PHP SUXXX” :-D

    • slicklash

      > Switch statements are static in a way that you cannot dynamically add/remove conditions or handlers.

      I agree, if you need dynamics switch is no use. The reason I compared them like that is that key set for hashtable is finite in your case (enums).

      > As for “default” clause, if you don’t find a registered handler in your map, you invoke the default one.

      As long as it is accepted behaviour.

      > As for enums, these things are unbelievably helpful for limiting user’s freedom of exceeding the allowed constant range.

      I agree they are, but not trivial and you can ensure limits without them.

      Let’s not speak about PHP anymore, it’s just a preprocessor.

  4. gugit

    You’ve killed all the fun of flaming.

    Now I need to come up with another trivial topic and start fierce debate about unimportant stuff.

    Damn :-(

Leave a Reply