Re^10: replace conditionals with polymorphism

Thank you for such a long and thoughtful response.

I apologize if you felt that I was baiting and switching, but my sense when I read Re^7: replace conditionals with polymorphism was that you had come to some incorrect conclusions about what I meant by applying OOP to your code. I was merely trying to clarify what I originally meant.

In particular, I don't think I ever suggested turning the tags themselves into objects. That would be rather silly in my opinion and destroy the whole structure of your original code. It would have been a variation on the ridiculous idea of encapuslating single case statements in objects - which I think I made pretty clear was ridiculous (even if I did it nicely). I seem to recall that my first post about OOPifying your engine specifically suggested that your tag processing functions could be turned into methods, not objects. But then again, if you read it otherwise, I wasn't being clear and I apologize for the confusion.

As for lisp - read it, use it (or rather its poor cousin elisp). Please don't think that because I am advocating an OOP wrapper in this case that I am limited to one paradigm. That is as bad as someone trying to trivialize your views by suggesting that they arise out of ignorance. And BTW I agree absolutely with Paul Graham and your post The world is not object oriented - as would Wittgenstein and the buddhist philosophers.

At some point, perhaps in a dedicated thread(?), I would love to have a discussion with you about when each paradigm is appropriate, are there rules of thumb for determining it, or is it purely a matter of experience and intuition (your 3X rule), and also how we teach it.

Best, beth

Update 2009-02-12: I realize in reading tilly's post below I have once again overstated my case. The idea of mapping tags to methods is part of a miniminal object representation - using no more OOP than is necessary to shield implementation and make the interface used by consumer code more likely to be stable. As the requirements became more clear, I completely agree with tilly that functions that took clumps of data and code references and generated families of token handlers might be a good idea. And I also might make judicious use of tags=objects. Or maybe even some approach that mixed the two paradigms. It really would depend on how needs evolve.

I guess we differ in that I would make handler generator functions into methods that would supplement the older tag=method approach. The key issue for me is that we have a cluster of related methods using at least some shared configuration data. I find (based on my own experience) that treating unrelated things as separate is inherently unstable, so I would like to hide my changing understandings of exactly how they are related behind an object. tilly would probably argue that since an object presumes the existence of relatedness, it is yet another one of those changing understandings, rather than a wrapper to hide those changes.

Comment on Re^10: replace conditionals with polymorphism

Replies are listed 'Best First'.
Re^11: replace conditionals with polymorphism by tilly (Archbishop) on Feb 11, 2009 at 21:42 UTC
My understanding of what you originally meant about applying OO to the code was from Re^6: replace conditionals with polymorphism where you wrote, ...turning the configuration data into the data portion of an object and the definitions of dispatch routines into methods. And then went on to discuss how you could get several different mini-languages by redefining 4 tokens (open tag, close tag, open constant tag, escape). My response to that was that the number of different types of tokens goes up rapidly when you add in convenience features like turning emoticons into pictures, autolinking URLs, and using \ as an escape mechanism. The result is that the number of different methods in your API quickly grows. You came back from that with the idea of putting an OO wrapper around the whole thing. I'm still unsure what that would buy. The basic problem is that your original suggestion was trying to draw an abstraction layer across the tight coupling between configuration and the handlers generated from that configuration. Tight coupling across a complex and young API is guaranteed to mean a lot of changes. A better idea is to have building the configuration hash broken up into a series of functions that return related sets of handlers. Like valid HTML tags, emoticons, automatic paragraph breaking, and convenience shortcuts. If this was for a discussion site like this one, you could then expose to the user the choice of which types of functionality they want available for processing their posts. And now even fairly significant rewrites of this code could take place without problems. Of course this approach doesn't lead you in an OO direction. On the question of how to select which paradigm to use when, I am a firm believer that programming should be viewed as a craft. Which, among other things, means that people need to be mentored. You can read all you like and be told all of the rules that exist without necessarily being able to apply it very well. But when you come up with a design and get detailed feedback on your design, things work much better. Mentoring online is better than nothing, but mentoring in person is much better. The fly in the ointment is where to get competent mentors from and match them up to programmers. I am all ears for a solution because I don't have one. However I had the luck to have a good mentor when I was just starting out, and I'm firmly convinced that that is the best way to go.	[reply]

Replies are listed 'Best First'.

Re^11: replace conditionals with polymorphism
by tilly (Archbishop) on Feb 11, 2009 at 21:42 UTC

Re^6: replace conditionals with polymorphism

...turning the configuration data into the data portion of an object and the definitions of dispatch routines into methods.

My response to that was that the number of different types of tokens goes up rapidly when you add in convenience features like turning emoticons into pictures, autolinking URLs, and using \ as an escape mechanism. The result is that the number of different methods in your API quickly grows. You came back from that with the idea of putting an OO wrapper around the whole thing. I'm still unsure what that would buy.

The basic problem is that your original suggestion was trying to draw an abstraction layer across the tight coupling between configuration and the handlers generated from that configuration. Tight coupling across a complex and young API is guaranteed to mean a lot of changes. A better idea is to have building the configuration hash broken up into a series of functions that return related sets of handlers. Like valid HTML tags, emoticons, automatic paragraph breaking, and convenience shortcuts. If this was for a discussion site like this one, you could then expose to the user the choice of which types of functionality they want available for processing their posts. And now even fairly significant rewrites of this code could take place without problems. Of course this approach doesn't lead you in an OO direction.

On the question of how to select which paradigm to use when, I am a firm believer that programming should be viewed as a craft. Which, among other things, means that people need to be mentored. You can read all you like and be told all of the rules that exist without necessarily being able to apply it very well. But when you come up with a design and get detailed feedback on your design, things work much better. Mentoring online is better than nothing, but mentoring in person is much better.

The fly in the ointment is where to get competent mentors from and match them up to programmers. I am all ears for a solution because I don't have one. However I had the luck to have a good mentor when I was just starting out, and I'm firmly convinced that that is the best way to go.

[reply]