How A Pull Request Rocked My World

http://clayallsopp.com/posts/the-story-of-pull-request/

by 10char • 13 years ago

320 151 13 years ago

clayallsopp.com

rasur• 13 years ago

IIRC, Fabio works at the Swiss Ruby shop Simplificator, who are all very nice chaps indeed! Glad he helped you along.

EDIT: I just checked, yes he does (well, unless we're talking about another Fabio of course, which is possible...)

herge2• 13 years ago

The classic "Replace Conditional with Polymorphism" design pattern, which took me way to long to realize that it also applies to Python.

ghc• 13 years ago

Indeed it does. I have a large code base at work that uses this pattern for Django models with a bit of metaprogramming to create a template for types of input sensors. It's amazing what this kind of refactor can do when you need to turn a long conditional into something more generally extensible. New sensor types with custom column configurations take an average of 5 lines of code now, instead of about 30 before.

deltasquared• 13 years ago

Yup. I remember that particular realization. Now switch statements in OO languages just look broken to me. Thanks Python!

jonathanberger• 13 years ago

Yes, it's cataloged in Martin Fowler's excellent book Refactoring, Improving the Design of Existing Code in Chapter 9.

I'd recommend the book strongly.

herge2• 13 years ago

Link for the lazy: http://www.refactoring.com/catalog/

Guillaume86• 13 years ago

I like this kind of refactoring, make you feel like: http://thejoysofcode.com/post/36047317385/when-i-replace-200...

lincolnq• 13 years ago

I don't love this refactor. I especially don't like how it generates names from other names -- e.g., given 'switch'/'submit', appends '_row', and then converts it to CamelCase so you get 'SwitchRow'/'SubmitRow', then instantiates the class named that.

Here's why: When I am maintaining somebody else's code, even if I guess that this is going on, I rarely trust these kinds of name-generation tricks. When I need to change some code, I'm going to grep the codebase for 'SwitchRow' and add a new line in whatever conditional to instantiate my new class. When grep can't find any instances of SwitchRow's constructor being called, I become suspicious and it costs me more time, because I am making sure I properly understand what is actually going on.

rosser• 13 years ago

...I rarely trust these kinds of name-generation tricks.

So you're probably not a big fan of Rails, then?

hnewser12• 13 years ago

and what does `trust` mean? You don't trust that correct object won't be given back to you?

diminish• 13 years ago

what about using a multiline YAML text to be loaded with automatic generation of objects from class name strings? (reminder!)

potatolicious2• 13 years ago

I'm actually not a huge fan of implicit name-generation tricks, but I'm also not entirely opposed to them.

The trick here I think is consistency - is name-generated type dispatch the standard across the entirety of the codebase? If it is, go wild. If it's not then I'd be much more wary of it.

Consistency and building correct expectations for future maintainers is pretty important. Doing a smart trick in one place but failing to do it in other places where it makes sense IMO tends to create a bigger mess than doing it the dumb-but-safe way everywhere.

tantalor• 13 years ago

Agreed. This "refactor" is actually a hack. It shouldn't pass code review.

scrid• 13 years ago

This is especially true for those of us who do application support.

When we are investigating application stack traces from production for a large application, it is awful when you discover that the developers decided to be clever with dynamic function names, making a large code base very difficult to support based on available logs.

If you think you're being clever you're probably just being a dick.

FuzzyDunlop• 13 years ago

Given this is ruby code, I think it's acceptable, and well-structured enough to be understandable.

While the implementation itself might be a bit 'eugh' because of the meta-programming involved, there was enough thought put into code organisation to allow you to grep `RowType` to find the module that namespaces all these dynamically instantiated classes.

Hell, if the code in the tree was arranged correctly, then `tree | grep row_type` would give you the folder where they all lived.

laureny• 13 years ago

tl;dr: polymorphism is usually better than if/else.

bfwi• 13 years ago

I like this explanation: http://stackoverflow.com/questions/234458/do-polymorphism-or...

mquander• 13 years ago

I don't agree with this change. Based on the code, it looks like there should be an enumeration of cell_types somewhere, a button should have a cell_type, and then there's a map from cell_type to construction_fn (or a polymorphic set of classes to serve as the map.)

Metaprogramming is something you do when you can't do it easily in the usual way. If a dispatch table or inheritance takes care of something, use the existing language features instead of building your own.

(EDIT: On examination, there already is a RowType, and the pull request is a lot closer to my suggestion than I first thought, so mostly ignore this.)

jtchang• 13 years ago

Refactors like this are super cool and often needed but I sometimes have to think why we don't store the easier to read code as well.

I know we have git and we can always do a diff to see what changed. What I am talking about is a more holistic view. Being able to search a code base for SwitchRow and then somehow the code comes up where it was refactored into this dynamic programming style.

Git can do this but only if you are actively looking for it. I wish you could do a metacomment on the refactor without cluttering up the code.

shocks• 13 years ago

Because if you understand the new code you don't need the "easier to read" code.

Constraining yourself to only writing code a beginner can understand is stupid. Maintaining good code and "easier to read for a beginner" code in tandem is a waste of man hours.

stickydink• 13 years ago

The article is very humble, but in my view, seems to go a little too far.

"You can reuse code with inheritance. Absolutely crazy. Brilliant.

All of this blew me away."

Honestly?

rco8786• 13 years ago

My thought exactly. Seems like a pretty basic usage of polymorphism/inheritance.

revelation• 13 years ago

Thats a very critical point that you just have to understand, to "get". Many people know and learn about object oriented design, but when tasked to actually write a program based on these principles they will often revert to code where they make distinctions based on the type of what they have been handed.

TLDR: dynamic_cast is bad design

mylittlepony13• 13 years ago

I guess he's gonna come back with another article when he realizes composition > inheritance.

to3m2• 13 years ago

Using static conditions rather than polymorphism seems to just be a common thing that people tend to do, regardless of skill level or quantity of experience. It's not uncommon for people just not to think of using polymorphism, if the objects in question wouldn't really model any particular kind of object as such (they're just there to provide a table of function pointers). This says nothing about the quality of their code, or the general OOness of their designs, or the number of digits in their IQ.

It's a bit of a shame, because I've found code to be reliably improved by using objects as simple tables of function pointers. The same is less often true for using objects as models of things.

eps2• 13 years ago

To each his own.

For me it was epoll() that blew me away. Absolutely crazy. Brilliant. But in retrospect so damn obvious.

misterS• 13 years ago

epoll() (or its predecessor poll()) is a kind of low-level API function, whereas polymorphism is a general and fundamental programming concept.

mylittlepony13• 13 years ago

At that point I closed the article and thought "Wtf HN, why was this on the front page?". Then I remembered that anything Ruby-related gets automatic upvotes, even if the author does not know the first thing about OOP.

pjmlp• 13 years ago

I also did not got the point.

It is as if the OP did not grasp what OOP is all about.

nathanstitt• 13 years ago

I didn't get that from the article. What I heard was the guy was amazed that someone took the time to attempt to better his code and (in his opinion) made it much better.

I agree with that a large extent - that's something that always amazes me about open-source. You're slogging along doing your thing, and then all of a sudden someone drops a huge patch on you that makes so much sense.

With that said; I did go back and re-read it, and your reading could be correct, it's hard to say. Does have a bit of humble brag to it for sure.

juddlyon• 13 years ago

Evocative writing for a technical post "serpentine" if/else, "rickety door" - I know nothing about iOS and enjoyed reading it.

iamdave• 13 years ago

I'm not a developer, but I read this article anyway.

All of this blew me away. Like this "@mordaroso" fellow strolled on up, cocked his knee skyward, and jettisoned his leg into the rickety wooden door that previously sheltered my mind.

That was just great writing.

mikeklaas• 13 years ago

I have to disagree. "Jettison" does not fit the simile he was going for, at all.

alecdbrooks• 13 years ago

It's not great, but it could be good. Replace "jettison" and cut the cliched "All of this blew me away" and the resulting paragraph is descriptive and fairly tight.

drakeandrews• 13 years ago

Jettisoning ones leg into a door sounds painful. Unless one has a prosthetic, then I must wonder why one is throwing it at a door. Do they not need it to stand?

cpeterso2• 13 years ago

I disagree. I had to parse the sentence three times to make all the pieces fit. :\

wcoenen• 13 years ago

This google tech talk is basically about the same thing, eliminating conditionals with polymorphism: https://www.youtube.com/watch?feature=player_embedded&v=...

guylhem• 13 years ago

On the first glance it seems great, but much more complex to understand and debug.

The if tree was certainly not pretty, but straightforward - it did its thing. It was something that could be given to an average developer to work on and improve.

The refactored code will require someone that's not just an average developer - if only because you need to read the article to understand it if you're not familiar with javascript, while the initial code needed only a glance to understand what it did.

IMHO, that's just complexity for complexity sake - unless you have plans to take advantage of the new flexibility it provides.

(and if you have to find, hire and pay that 'better than average' person, it might not be such a good thing.)

hnewser12• 13 years ago

This is not written in javascript, it is ruby. And I think your developer is way below average if he can't understand the pattern used in the refactored code.

dubcanada• 13 years ago

If you have a ruby programmer who can't understand this, fire them. And get a new one. This type of stuff is all over ruby code.

greenyoda• 13 years ago

It's scary to think that this guy who was just shocked to discover a very basic concept of object oriented programming (polymorphism) has written his own book on iOS programming:

http://clayallsopp.com/posts/writing-a-programming-book

AlexeyBrin5• 13 years ago

How many books did you wrote ?

mylittlepony13• 13 years ago

How is that relevant?

adamnemecek2• 13 years ago

Ah, the good ol' ad hominem.

icebraining2• 13 years ago

That's not an Ad Hominem.

martinced2• 13 years ago

I did write about twelve books and I still consider OP's point to be very valid.

The blog entry is great in that it shows how collaborating over the Internet can lead to improvement but it's indeed a bit concerning that someone who didn't know what polymorphism was had been publishing a programming book.

mylittlepony13• 13 years ago

"He is the creator of some of the most widely used RubyMotion libraries"

Then everyone is surprised when critical bugs come to light in Ruby stuff.

dhaivatpandya3• 13 years ago

I think this comment is a little unwarranted. Polymorphism wasn't the concept he discovered - the idea of generating the classes (metaprogramming) and the "clever" (well, some would say so at least) was interesting to him.

I also don't like how your comment tries to make fun of his efforts to learn something new.

mylittlepony13• 13 years ago

> I also don't like how your comment tries to make fun of his efforts to learn something new.

The problem is not that he's learning, he's teaching.

svachalek3• 13 years ago

In terms of Gang of Four patterns, I believe this would be Strategy + Factory Method. The book is a little antiquated (1994) but it or a better successor should be required reading for any programmer.

chris_wot7• 13 years ago

I don't believe that its terribly antiquated. Pretty much everything bases itself off of this book.

Edit: drafted iPad - fixed spelling. Trilby - does anyone even use that word anymore?!?

martinced2• 13 years ago

"I don't believe that it's the trilby antiquated. Pretty much everything bases itself off of this book."

Hardly.

The GoF book is sweet if in this day and age you're still doing Java/C# but if you're programming in a language like, say, Clojure you can throw about 75% of the GoF book into the trash.

pg said to use a Lisp to beat the average and that's what I'm doing. I'm certainly not accepting the status-quo and considering that, say, the "visitor pattern" is a godsend. Most of these "patterns" only make sense in a non-functional and OO language and are only needed because of missing languages concepts (like the lack of high-order function and/or the lack of real macros).

svachalek3• 13 years ago

It has a couple of patterns that have been more or less rejected by modern OO leaders:

1. "Singleton" (enough said) 2. "Template method" is more or less "inheritance over delegation"

There's also a couple like Flyweight that are of such narrow applicability that they hardly merit placement on the short list with classics like Composites and Factories, and a few new items like Dependency Injection are surely worth a mention whether you want to argue for or against it.

Finally it's got an approach to presenting and explaining the patterns that clearly predates the web and modern attention spans. All that said, it's still a classic, but depending on the preferred language and technical proficiency of the reader it wouldn't always be my recommended introduction to design patterns.

Xcelerate2• 13 years ago

Reading the comments in this thread is very interesting to me, because each programmer seems certain of the superiority of his own programming style.

We have some comments that disparage the change, saying that it obfuscates the code and makes it more difficult to understand.

We have others saying that this change is a basic technique and it's "shocking" that the author wrote a book without this simple knowledge.

What I take from this is yet another situation of people arguing about something highly subjective that is closely tied to their identity. Good programming is not an objective concept. People respond differently to different programming techniques and what works better for one person may greatly confuse another.

AlexeyBrin5• 13 years ago

+1 for Good programming is not an objective concept.

dakimov• 13 years ago

== Programming sucks nowadays.

There is not even a consensus on what is good in programming! Take a look at other professional cultures: people work extremely hard to develop the skills that everybody else in their profession have. What does a software developer do? Whatever they like on their own, there is no professional culture whatsoever: "Don't give a crap about the humankind's experience, I'll invent everything on my own the way I like".

This is actually unbelievable how different programming is in this aspect from other disciplines. I don't even mentor Junior Developers because of that, as I can't refer to anything authoritative and say "Do it like this" because there is always a bunch of folks that do it the opposite way. There is almost nothing to rely on.

nikster• 13 years ago

I dont agree with that.

There is a confusion about programming though, an idea that it is a purely technical discipline, like laying bricks when in reality its a design discipline, like designing a building.

If you wanted to build a house you wouldnt just hire a couple of bricklayers and tell them "do it". Yet thats what happens in programming...

pjungwir2• 13 years ago

Early in my career, a project manager said to me, "I've never heard one programmer praise another programmer's code. They always criticize!" I think that reinforced for me both that someone's approach might be good even if it isn't my own, and also that it's important to say when something is done well. Of course, there's also just a lot of bad code out there.... :-)

ams6110• 13 years ago

A lot of programmers are insecure. They were the nerds in school, not popular, not good at sports, etc. Programming is the one thing they can do where they feel in control, and confident. So they naturally tend to be defensive about it.

cubicle67• 13 years ago

I spent a few years as the sole maintainer of a moderately complex enterprise app written prettly much entirely in PLSQL. Hundreds of thousands of lines of it. By the time I left a reasonable proportion of that was code I'd added.

A few months after I'd left I got a phone call from the guy who'd taken over the project - he rang specifically to compliment me on the code and how easy it was for him to understand what was going on and how much better that had made his work. Didn't really know how to respond as I've never had that before, but it was nice.

Not blowing my own trumpet, so to speak (although it is something I'm kinda proud of) but to provide a counter data point to your PM's

muppetman• 13 years ago

I maintain an old ircII script. The guy that originally wrote it (srfrog - the LiCe script) is just an amazing programmer. The whole thing is clean and beautiful.

I feel ashamed when I touch it I dirty it up.

bgruber• 13 years ago

both arguments are right, but not because of a subjective goodness. because they're talking about 2 different parts of the patch:

- the "bad" part is RowType.for(), where a type is dynamically called forth based on manipulations on some string. I agree that a more concrete mapping from string-to-type would be preferable (I'm assuming the use of a string is required for some reason).

- the "good" part of the patch is that he replaced a conditional with type dispatch. I agree that this is a basic technique of object-oriented programming.

cbsmith• 13 years ago

A technique can be both basic/obvious and not a course of action that everyone would agree upon.

The surprise isn't that he didn't make the choice to do it that way. The surprise is that the choice didn't occur to him. The feedback would be very different if he simply had made a different choice.

B-Con• 13 years ago

I think that programming is very close to how we actually think. Programmers tend to be objective people who like distinguishing good from bad and better from worse. They're generally analyzers to the core.

But we all have some personal aspect of how we see the world. How we organize logic, view priorities, and such, is all personal and unique, no matter how much we may feel that it's objective.

Programming is an expression of that inner thought life. It's how you organize, categorize, and optimize, all laid out in bare raw form. It's an expression not just of our identity, but to an extent of how we exist. Being who we are, we usually tend to think highly of ourselves and our way of doing things, so it's only natural that we think highly our code style.

greghinch• 13 years ago

Something that I've come to realize only in the last couple of years: most programming arguments revolve around personal preference. There are of course optimizations that can be made to actually improve machine performance; these can be found reasonably simply through profiling. At the end of the day, most arguments revolve around "style".

It's actually a very tricky subject. If you're working on SMe apps, including startups, most often a given project'style will flow from the lead (or the person/people who initiated the project). They may be good, they may be bad. Invariably, less experienced developers are hired and learn Ro code following this style. Eventually, those less experienced developers become experienced, and leave to persue other projects. And they take that style with them.

Depending on the role they have, there is likely still a lead above them. And this is where the arguments begin. The lead had his/her style. The new dev has experience with another style, and it may or may not mesh with the new lead's style.

And so the problem perpetuates.

It can be very difficult to work with those devs in the early-middle stage of their career. If they are good people, they learn to be flexible, adopt the best parts of all the styles they are exposed to, and eventually become great leads. But many will not, are confrontational, and ultimately poisonous to the teams they are on.

If I can quote my favorite philosopher, Ted "Theodore" Logan: "if the only true wisdom lies in knowing, then you know nothing"

stiff• 13 years ago

A programming argument that can be convincingly shown to be only a matter of personal preference is irrelevant, but I strongly disagree those are that common. Various programming language constructs have various properties and if you had the opportunity to maintain a single project for some 5-10 years, to experiment with different implementations of same functionalities etc. you learn that certain techniques prevent problems and certain others provoke them.

Look at the writing of Joshua Bloch based on his experience with designing the Java standard libraries, you will find plenty of arguments that you could think are about "style", but in fact he always includes a very detailed and concrete discussion about why one way is superior to the other. Similarly with some of the articles of John Carmack from idSoftware. For me the revelation was that there is indeed no such thing as "style" so that some techniques are just "prettier" than the others, it is all a matter of consequences a given implementation has for other developers using the code and for its maintainers.

instakill• 13 years ago

I knew the comments were going to be exactly as you described before I clicked the comments link (and had this in mind http://xkcd.com/1053/) and I'm really glad your comment is on top and visible for everyone to digest before they start handing out their own judgements.

gdy• 13 years ago

These two statements are not mutually exclusive - the technique is basic and sometimes its drawbacks may outweight its benefits. While applicability of the technique in a particular situation may be a matter of discussion, ignorance of its existence is shocking considering that the author has reportedly written a book on programming.

Confusion2• 13 years ago

When people disagree that doesn't imply that the situation is highly subjective and all opinions are equally valid. In this case I believe they most certainly are not and I think you are drawing stronger conclusions than is warranted.

There are objective ways in which to judge programming, by considering whether simple rules like the SOLID principles, low coupling, DRY, using composition over inheritance, keeping code complexity measurements low, favoring immutability, statelessness and referential transparency, etc. have been followed.

If any programmer is certain of the superiority of 'his programming style' (singular), then that programmer is insufficiently humble and lacks knowledge of multiple programming styles. Tragically, if you don't know what you don't know, you can think you know everything and can thus speak with confidence on a subject.

One can wonder what comments would be left if you removed all those from programmers with less than 5 years of programming experience, programmers under 30 and programmers with experience in only a single language. My suspicion is that a pretty consistent picture would emerge, with a number of caveats and YMMV's, with an eye for the actual, intended and possible future use cases, the language, the maturity of the project, etc.

Xcelerate2• 13 years ago

I can agree with some of your points; however, I believe you make too many simplifying assumptions.

> There are objective ways in which to judge programming, by considering whether simple rules like the SOLID principles, low coupling, DRY, using composition over inheritance, keeping code complexity measurements low, favoring immutability, statelessness and referential transparency, etc. have been followed.

Hardly anyone on here would disagree that these are good programming practices (or so I think...), but the question becomes: what is the best way to favor immutability? FP solves that problem but many people don't like the all-or-nothing approach. Same with referential transparency.

> One can wonder what comments would be left if you removed all those from programmers with less than 5 years of programming experience, programmers under 30 and programmers with experience in only a single language.

Programmers under 30? Think how many languages exist that aren't even 30 years old! This is one area where I highly disagree. I have found that age matters very little with regard to someone's ability to write code. I have seen code written by "veteran programmers" that is worse than some teenager's weekend project. I'm not denying there is a correlation, but I would say it is a very weak correlation that probably isn't worth mentioning.

I do agree with programming experience, although I'll add the caveat that programming seems to be interesting compared to other subjects in that the rate at which different individuals become better at it seems to vary very dramatically.

efnx• 13 years ago

You're talking about the Dunning-Kruger effect, it's everywhere!

sbuccini• 13 years ago

To be honest, I'm very disappointed with the comments here.

Clay is obviously a very talented programmer, and just like most talented programmers, he didn't start out that way. This article isn't about how he learned OOP, it's about how someone opened his eyes to how code can be elegant instead of simply just functional.

This article hits home with me especially. I just learned Python last semester in my intro to CS class. I had an eerily similar moment when I learned how to use generators. "WOW! You can simplify this huge block of code into one line! It's..beautiful." It's a really special moment, and I'm glad Clay shared his.

leriksen• 13 years ago

Those who know this technique either discover it themselves, through "reading, learning, doing", or are shown,like this guy was. None of us was born knowing this. Clay has blogged about his experience of discovering this - that in itself is what makes this a great read for me. I wouldn't be surprised if every single tech book author, at some point after their book has been published, has learned something and thought "I wish I knew that when I wrote my book !!" By their very nature books document the authors understanding at a point in time. Would polymorphism have helped Clay's book ? Probably. Does not knowing it ruin the book ? Probably not. If we waited 'til we knew everything before we wrote a book about anything, nothing would ever get written.

AlexeyBrin5• 13 years ago

Writing a book is also a great way to discover new things about your subject.

nirvdrum3• 13 years ago

While true, when I purchase a book I'm trusting that the author is an expert in the topic. Maybe my expectations are too high.

ryanmolden• 13 years ago

Authoring a book and being an expert in the topic of said book is, surprisingly, not always correlated. I don't know this particular person, so don't read that as a comment on this particular author. I have met people whose books I have read, I have seen code written by these same people, I have talked with them about the book topic. My take away is that some people are good at writing books, some people are good at writing code, some, but definitely not all, are good at both.

chaz• 13 years ago

Critiquing these particular lines of code or the pull request is unimportant. My takeaway was that it's hugely valuable to simply make your code available and have other people look at it. Not only can it improve your own code, but you can personally learn something new from other people. You can be sure

Now I'm feeling a bit guilty for not having open sourced any of the code I've ever written, and I'm wondering what kinds of lessons I could have learned earlier on.

rckrd• 13 years ago

I would like to point out that he was able to describe his original implementation in a few sentences. This is important.

jules• 13 years ago

Novice programmer: Uses simple if/else.

Adept programmer: Discovers polymorphism. It's great, uses it for everything.

Master programmer: Realizes that in many cases, it makes the code less clear and more verbose, reverts back to if/else until the flexibility is actually needed.

Same story repeats itself many times on different fronts: metaprogramming, recursion, exceptions, macros, etc.

dougk16• 13 years ago

One more step: Master programmer realizes that they're still a Novice programmer - repeats the cycle.

rachelbythebay• 13 years ago

I tried to picture the solution before scrolling down past the initial block with the nested ifs. It got me thinking about "switch()", as seen in C, C++, and elsewhere. That in turn got me thinking about using an enum to pick up on whatever it is he's trying to do here, and jump to the right place accordingly.

Generically, I had something like this in my head:

    switch (row_type) {
      case submittable: ...; break;
      case checkable: ...; break;
      ...
    }

Then I started realizing that using a switch means you have isolated things such that they can only be one of the n types. It won't ever be submittable AND checkable, for instance. I assume that's what is desired here: mutual exclusivity for all of these possibilities.

Looking back at the original code, I see that by using the nested if/else construct, it effectively gives priority to them in the order in which they are encountered. A row with a submit_button is going to fire off make_submit_cell() whether or not it has checkable set. It trumps the possible call to make_check_cell, in other words.

These two approaches solve two different problems. Without knowing more, it's hard to say whether the "priority" approach makes sense here.

If I had to guess, based on the refactoring which turned it into a series of distinct classes, that sounds like it should have been "pick 1 of n" (one-hot code) all along. If that's so, the if block wasn't just ugly, but it was actually covering up some real problems. It was just asking for trouble in terms of bugs down the road since it allowed nonsensical settings.

But that's just a guess. I could be wrong.

potatolicious2• 13 years ago

Indeed, the original code was, IMO, incorrect.

It looks like the purpose is a pretty common one in iOS - you have a table view populated by many rows, each of which can be a different class that renders and behaves differently. It's a common need in iOS apps.

What he really needed was an enum, not flags. The choice of class is mutually exclusive and flags are horrible for tracking this, and are great for hiding bugs - one erroneous flag flip and suddenly your code is walking down a completely different path that's non-obvious on first debug. Using a bunch of bools to approximate state is error-prone and IMO just bad architecture.

jQueryIsAwesome• 13 years ago

I do something a little bit similar with DOM interaction in JS, for example button ".btn_pdf_docs" shows all ".pdf_docs" elements. I consider the code to implement this more readable than a bunch of events binding.

campnic• 13 years ago

I like Martin Fowler's Refactoring. This is called 'Replace conditional with subtype' explained here: http://www.refactoring.com/catalog/replaceConditionalWithPol...

The book is a good read and a fantastic reference.

jamieb• 13 years ago

This person found something that they didn't know they didn't know and were so happy they blogged about it. Regardless of what I may personally think about the merits of the code before or after, it makes me happy that there is another human being who is thrilled by learning something new about programming.

davidrudder• 13 years ago

I like it when developers praise each other.

vemv• 13 years ago

Fabio's approach does the job, but it fails at genericity - its usefulness is limited to the scope of the Formotion project. Which is unfortunate because something actually simple is going on - a mapping of keywords to functions.

What you really want is multimethods - they provide all the goodness of classic polymorphism, without forcing you to model intrincate, rigid class hierarchies/relationships.

Some pseudocode illustrating the concept:

    # declaration. the 'dispatch function' we pass can build an arbitrary value out of the args it receives.
    defmulti build_cell lambda { |args| args[1].tag }
    
    # if the value the dispach function generates equals :submit, this body is gonna be called
    defmethod build_cell :submit do
        # implementation...
    end
    
    # more defmethods for :switch, :check, :edit etc
    
    build_cell(row, cell)
    # our lambda gets invoked, which re-passes the arguments it receives to the corresponding implementation

Multimethods doesn't seem to be have been adopted at all in the Ruby community. A quick googling reveals a couple implementations though.

In the Lisp world they are first-class, even though they aren't used all the time. http://clojure.org/multimethods might be worth a read.

roestava• 13 years ago

Ruby is so unique. Back when I was also surprised by Ruby's reflection and metaprogramming features. So much easier than it was in the languages I had used before.

Nowadays I see people wanting to change Ruby to be more like those other languages. Needless to say, Ruby is best when all of Ruby is available. Putting restrictions on it wouldn't begin to turn it into what some people want.

On the server-side, people can use all kinds of languages, with no restrictions on choices. That's why these languages can flourish. On the client-side we are more restricted. The industry gets to dictate what goes on the client-side more.

Sigh.

I'm trying to use Dart lately which compiles to Javascript. While it can seem a bit like Ruby in OO and dynamic typing, it's a world of difference in other regards. Languages like Ruby that can evolve while breaking backward compatibility have more chance to be useful out of the box.

robbles• 13 years ago

Can you imagine how much more pleasant participating in HN, GitHub, etc. would be if all programmers were this pleasant and open-minded?

Regardless of the particular merits of the technique he talks about here, I think we can all learn a lesson from this guy about appreciating the work and ideas of others.

gruseom• 13 years ago

I couldn't agree more. The ability to appreciate others' work is a sign of intelligence.

reyan2• 13 years ago

I would not go for polymorphism (specially with all that meta-programming) with this simple conditional.

jakejake• 13 years ago

I liked the article because I feel like I'm at the stage of my career that I need to be a mentor. But at the same time I don't feel like I know enough about everything.

Here is someone writing books and programming iOS apps who can still have his mind blown by, what seems to me, some fundamental concepts. I think there are a lot of people out there doing real work - who can benefit from a little push. that makes me feel that a) I have things I can teach and b) that its ok to not know everything - even what others may think is "basic" stuff.

10char• 13 years ago

I was confused as to how a lot of folks took the post to mean I didn't know what polymorphism was...and then I experienced the whole Arrested Development-esque "I've made a huge mistake," probably a little too late.

A lot of folks drew attention to "You can reuse code with inheritance. Absolutely crazy. Brilliant." and took as equivalent to me saying "It's absolutely crazy and brilliant you can reuse code with inheritance." I get that both in- and especially out-of-context that's how it comes off, but it's not what I meant. It was sloppy and I should've been more careful in writing.

I meant it to come off more like "...everything is dynamic and decided at run-time, plus you get a great plugin architecture if you do some polymorphic tricks with these RowType objects. And all of these benefits came from just one simple refactoring. The power of small refactors is absolutely crazy. Brilliant." (I've added this as an addendum to the post)

Like the point of the whole thing wasn't about the refactor itself and if/how the code "rocked my world", but the fact that a refactor could have a seismic effect on the future of a project and the direction it takes.

The addition of many more row "types" wasn't even in the orbit of my thinking without the refactor, and it really helped shape where the project went: there were just those 4 branches in the `if`/`else` tree in this post, but there are now 20-odd default row configurations.

Hope that helps some folks to add more context

tylerc230• 13 years ago

Sounds like the open/closed principle of SOLID development. "Objects should be open to extension but closed to modification". This basically means that users of your code shouldn't have to modify your classes to add functionality. It should be done through inheriance and adding new types. http://en.wikipedia.org/wiki/Open/closed_principle

How A Pull Request Rocked My World

Related Stories