• p (unregistered)

    It might make sense (maybe!) as part of a general command-line parser of sorts, which invokes commands with arguments passed as Object[]. So the cast to boolean would be in a specific command.

  • (nodebb)

    And the parse* seem to be defined in the same class so one can only imagine the kind of magic they hold.

  • (nodebb)

    Feels like overkill, but yes, if you don't have a type safe language it is up to the developer to ensure type safety with dozens and hundreds of automated tests and tons of redundant type checks. Or just use TypeScript instead. That works too.

  • (nodebb) in reply to MaxiTB

    using typescript would make more sense if the original code was javascript. which isn't the case in this particular example.

  • Marvin (unregistered) in reply to p

    Still doesn't save you anything - you'll have to do the actual type check, so this method is just chaff. TryParse() is your friend here. If one insists on writing a generic method, there's ... well, generics, System.Convert and reflection magic. (I can't recommend it, personally - it's almost never worth the hassle.)

  • (nodebb) in reply to MaxiTB

    Feels like overkill, but yes, if you don't have a type safe language it is up to the developer to ensure type safety with dozens and hundreds of automated tests and tons of redundant type checks. Or just use TypeScript instead.

    I don't think this is relevant. If you store all of your data in strings, then try to get them back out, you're going to have conversion issues whether you have a type safe language or not. It's not like Java prevents some dolt from storing true as "Yup!".

    The sadness of this article is that some code was written, and that code solves no problems while making converting stringly typed data harder (or at least no easier). Strong or weak typing, I can't see very many cases where you want a function that tries to convert a string into some type, without knowing what type you need as a result. This code might be easier to write and would probably be slightly less weird to call in javascript, but it would still be useless.

  • (nodebb) in reply to thosrtanner

    Oh your are right, it's a Java developer. Now it makes even more sense :-)

  • Loren Pechtel (unregistered)

    It's parsing unknown data, probably into an array of objects. Some downstream consumer can accept or reject it, said consumer doesn't need to know where it came from.

  • NextRelease (unregistered)

    So fun fact, the implementation of parseBoolean is pretty straightforward: return "true".equalsIgnoreCase(s); Meaning this will always return a boolean value, and the rest is dead code.

  • Nick (unregistered)

    I would assume that the consumer of this code would then use an “instance of” check when handling the return value.

    Just because the function returns an Object doesn’t mean we lose all runtime type information!

Leave a comment on “Objectifying Yourself”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article