Robert W. wrote:
Marnen Laibow-Koser wrote:
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.)
So you’re saying here that Cocoa MUST be poorly designed, and Obc-C is
weird, because you don’t understand it?
No, that’s absolutely not what I meant; sorry if I was unclear. I
- You seemed to be saying that we should use this pattern because Cocoa
does. My respose was that yes, that’s possible, but it’s also possible
that Cocoa made a mistake. I make no judgement on which is the case; I
merely wanted to point out the other possibility. As far as Obj-C being
weird, well…I think it is. That doesn’t mean I dislike it; in fact, I
think it’s kind of neat. But a C-Smalltalk hybrid is like
garlic-flavored ice cream: even if you like the way it tastes, it’s
still conceptually odd.
How about let’s leave the code
bigotry out of the discussion.
Happy to. No code bigotry was meant on my part at all.
What does make a difference is that Cocoa is a desktop
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
with a more extensive use of the MVC pattern than
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, I agree. Cocoa implements the “original” MVC design pattern (with
Yes, that was my impression. Rails’ MVC is a bit idiosyncratic.
MVC actually does predate the web itself after all.
I know. And Reenskaug-style MVC is probably not that well suited to the
Web without some modifications (I’ve just been reading a bunch of stuff
on Ward’s Wiki about this, in fact).
Yes. And it may be that your approach has some benefits that I haven’t
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
If you consider separation of responsibility a benefit, then the
formatter pattern has the same benefit as the MVC design pattern.
Formatters can be attached to other view objects, such as text fields or
any other view object responsible for displaying, validating and
interpreting data. This attachment can then be implemented and managed
completely within the view layer isolating the responsibility from the
model and controller layers.
Perhaps. I’ll have to think about this some more. This looks like
about the same thing as the Presenter pattern that Jay Fields has
written about, and frankly, I’m suspicious of it. It looks like
needless complexity and/or too much logic in the view layer.
Or are you saying that one could potentially use the same
Formatter/Presenter for two completely different underlying models?
That could certainly be an advantage of introducing the extra layer.