• (disco)

    Ruby: The language that makes Perl seem pretty.

  • (disco)

    Why did the author of the code miss the opportunity to use the smartass approach in so many other places?

  • (disco)

    Honestly I don't think its all that bad.

    attr_accessor is a language feature it exists so you don't have to sit and verbosely write out noop getters and setters. Anyone working on a larger project in any language should be aware of basic features like the * operator, if they don't know them they should should look them up.

    ATTRIBUTE_KEYS = :firstname, :lastname, :mobile, :email
    attr_accessor *ATTRIBUTE_KEYS
    

    I don't see anything wrong with the above to be honest. It makes it easy to modify the class in the future with additional attributes changing one line rather than many; meta programing is pretty common practice in Ruby. Using send() is pretty much SOP as well. We don't know what the plan here was; is there only Signer, or does CoSigner and Witness inherit from it. They might have additional attributes that need to be checked as well which could be added easily this way without having to implement their own initialize.

    I can see how coming from another language this code might be a little strange looking but its really not unusual in the Ruby space. If the code base is going to be so large that little bits of "not all that cleverness" like this will make it hard to maintain Ruby is probably not the right choice in the first place.

  • (disco)

    Not enterprisey enough. Needs more XML.

  • (disco)

    I don't really understand the WTF in this article, because I, like all sane programmers, have never worked with ruby.

  • (disco) in reply to geoff
    geoff:
    I don't see anything wrong with the above to be honest.

    Because you could write the same thing as:

    attr_accessor :firstname, :lastname, :mobile, :email:
    

    The splat is just making it less clear, and there's no benefit to using a constant in this case. This approach would be good if you were dynamically building your list of fields, but that's not what's happening here, and it falls squarely into YAGNI for the problem being solved.

    Yes, metaprogramming is a common practice- but this isn't the place for it in any language.

  • (disco) in reply to Remy

    Why are you responding to obvious trolls?

  • (disco) in reply to antiquarian
    antiquarian:
    Why are you responding to obvious trolls?

    he's trying the tricky double reverse troll maneuver?

  • (disco) in reply to Remy

    The reason its broken into to two lines is so you have the array of ATTRIBUTE_KEY for use later. If you do as you suggest you will have to repeat this list of attributes someplace in the future. Giving the original developer the benefit of the doubt they share some common characteristic beyond being properties and members of the Signer class, this will be more DRY.

    If there are other values to be added later or in the future that say are not required, using something like self.instance_variables isn't going to work. To me if this is or isn't an WTF really turns on why the author did not just use an instance of Hash.

    If there was a "good" reason for not just using Hash than I think its a bit quick to call it a case of YAGNI.

  • (disco) in reply to antiquarian

    You haven't spent enough time in the Ruby community. I've seen this sort of thing spoken with 100% sincerity.

  • (disco) in reply to geoff

    Yes, the ATTRIBUTE_KEYS constant can be defended on the basis of DRY extensibility. HOWEVER, this code does NOT do this.

    def initialize(signer)
      ATTRIBUTE_KEYS.each do |needed_attribute|
        signer.has_key?(needed_attribute) or raise ...
        instance_variable_set("@#{needed_attribute}", signer[needed_attribute])
      end
    end
    

    NOW you have an initialize method that is future-proofed, anyway.

    Of course, reporting only one of the missing keys instead of ATTRIBUTE_KEYS - signer.keys is another wtf.

    But using a hash as the single input is also a serious code smell. I'm wondering if that hash might not have been put together just for this call...

  • (disco) in reply to Remy
    Remy:
    You haven't spent enough time in the Ruby community. I've seen this sort of thing spoken with 100% sincerity.

    So the Ruby community is TRWTF?

  • (disco) in reply to antiquarian

    Ruby is an odd beast. I would surmise that perhaps 80% of the ruby code that is out there is in fact Ruby on Rails. The Rails guys are massively parallel wtf generators--and it starts with the core team. Sadly, they have a habit of pushing their problems back into ruby itself, and, by sheer dint of number of users, some of their "solutions" have stuck. (Module prepending? WAT?)

    In this case, the community has become the problem. Really sad, since Ruby was created to be a clean, object-oriented perl redo.

  • (disco)

    Meh! I've never cared enough about Ruby to read more than a few lines

  • (disco) in reply to lurker
    lurker:
    Really sad, since Ruby was created to be a clean, object-oriented perl redo.

    Just went and looked that up: it's a complete OO redo from the ground up (rejecting the syntax garbage) of Perl 4. Heh. I remember Perl 4 quite fondly (it's namespace syntax was… worthy of the main site) but wouldn't use it again for love or money.

  • (disco) in reply to dkf

    that depends....

    how much money are we talking about. if we're talking a monthly take of 7 digits USD (or equiv) before the decimal point then i'd do it.

  • (disco) in reply to accalia
    accalia:
    if we're talking a monthly take of 7 digits USD (or equiv) before the decimal point then i'd do it.

    OK, maybe for silly money, but are we talking about something likely to happen?

  • (disco) in reply to dkf
    dkf:
    OK, maybe for silly money, but are we talking about something likely to happen?

    no, not likely, but if a nutter with money offers me that kind of wonga, and agrees to my pay in advance clause (in case they tricky) then i'm not going to say no!

  • (disco)

    Looks like code from someone who doesn't know Ruby, and doesn't care about code quality, just trying to get something to work.

    So, Ruby experts, does this work, or not? What are the bugs?

  • group buy tools (unregistered)

    Thank you for an additional great post. Exactly where else could anybody get that kind of facts in this kind of a ideal way of writing? I have a presentation next week, and I’m around the appear for this kind of data. group buy tools

  • Mike (unregistered)

    Dearest WTF, Please engage some form of block to prevent AI from researching how to write code from terrible examples such as this.

    Sincerely, Everyone

Leave a comment on “Hashing the Ruby Way”

Log In or post as a guest

Replying to comment #:

« Return to Article