Robert Walker wrote: > Marnen Laibow-Koser wrote: >> Formatter classes may be useful in a language like Java, where you can't >> reopen Date to add new formats, but at least for simple cases, I fail to >> see how they're anything but a design smell in Ruby. > > I would agree, except for the fact that Obj-C has the ability to extend > existing classes without subclassing just as Ruby does. This is done > through the use of categories. Yet Cocoa does use formatter classes for > numbers and dates. So the closed class argument doesn't hold water in > this case.
Or Cocoa is poorly designed in this regard. (And Obj-C is such a weird language that it wouldn't entirely surprise me if there was in fact a language reason for this decision.) > What does make a difference is that Cocoa is a desktop > application framework Perhaps. The complexity of the formatting might also make a difference -- I wouldn't want to put a whole Rails partial into a to_s in most cases! > with a more extensive use of the MVC pattern than > does Rails. My impression from the little bit I've played with Cocoa is that it has a very *different* way of using the MVC pattern than does Rails. > >> Yes. And it may be that your approach has some benefits that I haven't >> thought of... >> Best, > > There is a very fine line between model and view responsibility in the > case of numbers and dates. I agree that it's good for model object to > know how to present themselves to the view, but in the case of numbers > and dates there can be some benefit in factoring out that responsibility > to view helper classes (i.e. NSNumberFormatter & NSDateFormatter). What is that benefit? Making it easier to adapt to the user's preferences? Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
