The Problems with NSController

  • While working on the second edition of "Cocoa Programming for Mac OS
    X," I have spent a good chunk of time working with NSController and the
    bindings mechanism. And I have bad news: they are poorly designed and
    poorly implemented. I sincerely hope that this technique is deprecated
    because it will become embarrassment for Apple and the entire Cocoa
    community.

    History first: NeXT used to compete in the client-server market against
    products like PowerBuilder. Minimizing the glue code necessary to write
    applications that displayed tables of data was very important. So we
    developed the Enterprise Object Framework (EOF).

    EOF had an NSController-like mechanism that used a class called
    NSAssociation. NSAssociation objects worked like the bindings mechanism
    -- they were a smart link between the controller and the user interface
    object.

    People loved EOF. I don't know how many times I heard the following: "I
    used to use PowerBuilder, but it made 90% of the application easy to
    write and 10% impossible." NSAssociation and careful use of delegation
    made EOF easy to extend.

    NSController and the binding mechanism suffers from PowerBuilder-like
    shortcomings: As long as you do exactly what the designer planned, it
    is quite convenient, but the moment you wander off this narrow trail,
    misery ensues.

    Here are the basic design flaws that plague NSController and the
    bindings mechanism:

        1.     It eschews the delegation design pattern. This makes it
    difficult to extend and inconsistent with the rest of Cocoa.

        2.     It uses a lot of private APIs. NSAssociation has been replaced
    by NSBinder and NSBinderAdaptor. NSAssociation, however, was public and
    easily subclassed. NSBinder and NSBinderAdaptor are private and
    undocumented. Altering the default behavior of the bindings is
    impossible.

        3.     It has no support for undo. EOF automatically registered all
    edits, inserts, and deletes with the undo manager.

        4.     It has no support for relational databases. EOF could bundle all
    those edits into tidy SQL statements and put them into a relational
    database for you. This was made possible by a carefully defined data
    source protocol. You could easily create your own data sources and slip
    them under the controller.

        5.     It relies on unsavory hacks to the runtime system. For a
    controller to know about changes to a model object, your accessor
    methods need to notify it of the change. In EOF, the developer added a
    call to [self willChange] to each set method in his model objects.
    NSController (which doesn't trust you to do this) replaces your class
    with a secret subclass that does the "right" thing.

        6.     It was created in a vacuum and rushed to market. No one at Apple
    has ever created a realistic application with NSController.  The
    design,  the implementation, and the documentation would all be better
    if someone at Apple had been required to actually use NSController.

    (Note that this is not a list of bugs -- those will disappear in time
    -- but only basic design errors.)

    I have met a few people who claimed that EOF was hard to use. These
    people, regardless of what was written their business cards, were not
    programmers. I'm glad that they decided to work in PowerBuilder or
    Visual Basic -- I'm certain that regardless of the tool they chose,
    these people never produced an application of any worth. EOF and Cocoa
    were designed to give real power to real programmers. NSController and
    the bindings mechanism were designed to give power to people doing
    demos.

    If good demos is the goal, NSController is sufficient, but if Apple is
    serious about the enterprise, they should take a long, hard look at
    this poorly thought-out mechanism and yank NSController. They could
    replace it with something more like EOF. Heck, they could just
    recompile the old Objective-C EOF source code.

    These are harsh words, but someone should have stopped this train a
    long time ago. The best I can do now is tell you not to get on.

    Sincerely,
    Aaron Hillegass

    (To prevent a bunch of emails, let me mention that you will not be able
    to buy the second edition of "Cocoa Programming for Mac OS X" for many
    months. If you want a copy of the current draft, you should come to
    class at the Big Nerd Ranch. We are offering a class Nov 10 - 14 in
    Atlanta.)

    (I've put a copy of this on the Big Nerd Ranch website:
    http://www.bignerdranch.com/Resources/nscontroller.html
    )
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On dimanche, octobre 26, 2003, at 03:42  PM, Aaron Hillegass wrote:

    > [...]
    > NSController and the bindings mechanism were designed to give power to
    > people doing demos.
    >
    > If good demos is the goal, NSController is sufficient, but if Apple is
    > serious about the enterprise, they should take a long, hard look at
    > this poorly thought-out mechanism and yank NSController. They could
    > replace it with something more like EOF. Heck, they could just
    > recompile the old Objective-C EOF source code.
    >
    > These are harsh words, but someone should have stopped this train a
    > long time ago. The best I can do now is tell you not to get on.

    Damn.. Why was I preventing myself from writing that NSController was
    the return of the NSTextView demo with the inability to reproduce right
    away the demo for the attendee?
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • You also have to remember that a lot of people won't start using
    NSController for a while. It is not backwards-compatible with Jaguar. Who in
    their right mind would write a program that will *only* work in an operating
    system that is less than 3 days old? Perhaps Apple considered this and
    simply placed the current "version" of the Controller class in Cocoa and
    XCode as a placeholder for something else they are currently designing. They
    figure that no one will really use it outside of demos and tutorials they
    provide, so why make it perfect the first time around?

    I know that I won't be using the Controller stuff until many, many months
    from now, when Apple assures developers that the majority of Mac users are
    using Panther and not Jaguar. The same thing went when Jaguar was first
    introduced. People still had to write software that was backwards-compatible
    with OS X 10.1 and 10.0, and they didn't start specializing their software
    for Jaguar until 3 or 4 months after its release, perhaps even longer.

    - Marc W.

    On 10/26/03 9:42 AM, "Aaron Hillegass" <info...> wrote:

    > While working on the second edition of "Cocoa Programming for Mac OS
    > X," I have spent a good chunk of time working with NSController and the
    > bindings mechanism. And I have bad news: they are poorly designed and
    > poorly implemented. I sincerely hope that this technique is deprecated
    > because it will become embarrassment for Apple and the entire Cocoa
    > community.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • Am Sonntag, 26.10.03 um 15:42 Uhr schrieb Aaron Hillegass:

    > 5.     It relies on unsavory hacks to the runtime system. For a
    > controller to know about changes to a model object, your accessor
    > methods need to notify it of the change. In EOF, the developer added a
    > call to [self willChange] to each set method in his model objects.
    > NSController (which doesn't trust you to do this) replaces your class
    > with a secret subclass that does the "right" thing.

    I just wondered about this point when reading the documentation.

    Too bad. Sounded like a great concept.

    bye.  Andreas.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On 26 okt 2003, at 16.37, Andreas Mayer wrote:

    > Am Sonntag, 26.10.03 um 15:42 Uhr schrieb Aaron Hillegass:
    >
    >> 5.     It relies on unsavory hacks to the runtime system. For a
    >> controller to know about changes to a model object, your accessor
    >> methods need to notify it of the change. In EOF, the developer added
    >> a call to [self willChange] to each set method in his model objects.
    >> NSController (which doesn't trust you to do this) replaces your class
    >> with a secret subclass that does the "right" thing.
    >
    > I just wondered about this point when reading the documentation.
    >
    > Too bad. Sounded like a great concept.

    It should be noted, though, that this behaviour is optional. You can
    choose to disable automatic "KV Observer Notification" (+[NSObject
    automaticallyNotifiesObserversForKey:]), and then you have to call
    -willChangeValueForKey: to give manual notification of value changes.

    I have not spent enough time actually working with NSController to have
    formed an opinion on wether it is well designed or not.

    / Regards, David
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Sunday, October 26, 2003, at 03:26  pm, Marc Weil wrote:

    > You also have to remember that a lot of people won't start using
    > NSController for a while. It is not backwards-compatible with Jaguar.
    > Who in
    > their right mind would write a program that will *only* work in an
    > operating
    > system that is less than 3 days old? Perhaps Apple considered this and
    > simply placed the current "version" of the Controller class in Cocoa
    > and
    > XCode as a placeholder for something else they are currently
    > designing. They
    > figure that no one will really use it outside of demos and tutorials
    > they
    > provide, so why make it perfect the first time around?

    It's also worth saying that NSController is still pretty neat, for all
    its apparent flaws... many of us that don't have a
    NeXTStep/WebObjects/EOF background haven't seen anything quite like it
    before, and it is still the case that it will allow people to create
    software with fewer lines of code.

    OK, perhaps EOF was better, but we don't have EOF.  If people (like
    Aaron) want EOF to reappear, perhaps they should file a bug report with
    Apple?  Or even use the e-mail addresses that were handed-out at WWDC
    to lobby the people responsible for the Cocoa frameworks (they said
    they wanted to know how we'd like them to improve things, right?)

    Also, if Apple do bring back EOF, then from what Aaron said in his
    original e-mail, it sounds as if it would be possible to re-implement
    NSController in terms of EOF (OK, you'd still have the secret subclass
    hack, but we're just going to have to live with that).  So perhaps we
    shouldn't worry too much at this point?

    Kind regards,

    Alastair.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • > From: Aaron Hillegass <info...>
    > Date: Sun, 26 Oct 2003 09:42:15 -0500
    > Subject: The Problems with NSController
    >
    > If good demos is the goal, NSController is sufficient, but if Apple is
    > serious about the enterprise, they should take a long, hard look at
    > this poorly thought-out mechanism and yank NSController. They could
    > replace it with something more like EOF. Heck, they could just
    > recompile the old Objective-C EOF source code.
    >
    > These are harsh words, but someone should have stopped this train a
    > long time ago. The best I can do now is tell you not to get on.

    Your argument to me sounds like "if it isn't EOF, it sucks". I've been using
    NSController & co for a while now and it works for me (despite some problems
    I'm happy to put down to 'learning curve').

    The net effect is that NSController reduces the number of lines of code in
    my projects and that makes them easier to maintain and extend. I don't
    really care whether it "hacks the runtime system", or if Apple isn't using
    NSController in their projects (yet). Some of your points have merit (like
    missing undo support and private APIs) but quite frankly this kind of scare
    mongering isn't particularly useful.

    To me - the biggest problem with the NSController technology is that it's
    10.3 and up only.

        Jon.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • To Aaron's defense, his criticism is very constructive.  For my part,
    I've just begun to play with NSController so my comments are to be
    interpreted in the light.  I've decided to reply to this thread, since
    I figured that a considerable number of Developers are in my same
    position.  To get to my point, I don't really see where this is going
    to be really useful...

    It may eliminate a few lines code but so what? I found the notification
    mechanism a bit clumsy and one that will not make a beginner's life any
    easier.  So if this is not for beginners then who is it for? Experience
    programmers don't care about writing a few lines of extra code, if it
    means more control.  It would have been nice to be able to abstract SQL
    calls in some way -I'm not of the EOF generation, although in the right
    age group.

    I will continue to dig into this but merely out of academic curiosity.
    I hope that  Apple provides some more examples of where the real value
    is.  At this point it seems to be trade off between not writing some
    extra (very easy) code and the intuitiveness of dragging wires from IB
    widgets to a standard controller.

    Francisco

    On Oct 26, 2003, at 8:42 AM, Aaron Hillegass wrote:

    > While working on the second edition of "Cocoa Programming for Mac OS
    > X," I have spent a good chunk of time working with NSController and
    > the bindings mechanism. And I have bad news: they are poorly designed
    > and poorly implemented. I sincerely hope that this technique is
    > deprecated because it will become embarrassment for Apple and the
    > entire Cocoa community.
    >
    > History first: NeXT used to compete in the client-server market
    > against products like PowerBuilder. Minimizing the glue code necessary
    > to write applications that displayed tables of data was very
    > important. So we developed the Enterprise Object Framework (EOF).
    >
    > EOF had an NSController-like mechanism that used a class called
    > NSAssociation. NSAssociation objects worked like the bindings
    > mechanism -- they were a smart link between the controller and the
    > user interface object.
    >
    > People loved EOF. I don't know how many times I heard the following:
    > "I used to use PowerBuilder, but it made 90% of the application easy
    > to write and 10% impossible." NSAssociation and careful use of
    > delegation made EOF easy to extend.
    >
    > NSController and the binding mechanism suffers from PowerBuilder-like
    > shortcomings: As long as you do exactly what the designer planned, it
    > is quite convenient, but the moment you wander off this narrow trail,
    > misery ensues.
    >
    > Here are the basic design flaws that plague NSController and the
    > bindings mechanism:
    >
    > 1.     It eschews the delegation design pattern. This makes it
    > difficult to extend and inconsistent with the rest of Cocoa.
    >
    > 2.     It uses a lot of private APIs. NSAssociation has been replaced
    > by NSBinder and NSBinderAdaptor. NSAssociation, however, was public
    > and easily subclassed. NSBinder and NSBinderAdaptor are private and
    > undocumented. Altering the default behavior of the bindings is
    > impossible.
    >
    > 3.     It has no support for undo. EOF automatically registered all
    > edits, inserts, and deletes with the undo manager.
    >
    > 4.     It has no support for relational databases. EOF could bundle
    > all those edits into tidy SQL statements and put them into a
    > relational database for you. This was made possible by a carefully
    > defined data source protocol. You could easily create your own data
    > sources and slip them under the controller.
    >
    > 5.     It relies on unsavory hacks to the runtime system. For a
    > controller to know about changes to a model object, your accessor
    > methods need to notify it of the change. In EOF, the developer added a
    > call to [self willChange] to each set method in his model objects.
    > NSController (which doesn't trust you to do this) replaces your class
    > with a secret subclass that does the "right" thing.
    >
    > 6.     It was created in a vacuum and rushed to market. No one at
    > Apple has ever created a realistic application with NSController.
    > The design,  the implementation, and the documentation would all be
    > better if someone at Apple had been required to actually use
    > NSController.
    >
    > (Note that this is not a list of bugs -- those will disappear in time
    > -- but only basic design errors.)
    >
    > I have met a few people who claimed that EOF was hard to use. These
    > people, regardless of what was written their business cards, were not
    > programmers. I'm glad that they decided to work in PowerBuilder or
    > Visual Basic -- I'm certain that regardless of the tool they chose,
    > these people never produced an application of any worth. EOF and Cocoa
    > were designed to give real power to real programmers. NSController and
    > the bindings mechanism were designed to give power to people doing
    > demos.
    >
    > If good demos is the goal, NSController is sufficient, but if Apple is
    > serious about the enterprise, they should take a long, hard look at
    > this poorly thought-out mechanism and yank NSController. They could
    > replace it with something more like EOF. Heck, they could just
    > recompile the old Objective-C EOF source code.
    >
    > These are harsh words, but someone should have stopped this train a
    > long time ago. The best I can do now is tell you not to get on.
    >
    > Sincerely,
    > Aaron Hillegass
    >
    > (To prevent a bunch of emails, let me mention that you will not be
    > able to buy the second edition of "Cocoa Programming for Mac OS X" for
    > many months. If you want a copy of the current draft, you should come
    > to class at the Big Nerd Ranch. We are offering a class Nov 10 - 14 in
    > Atlanta.)
    >
    > (I've put a copy of this on the Big Nerd Ranch website:
    > http://www.bignerdranch.com/Resources/nscontroller.html
    > )
    > _______________________________________________
    > cocoa-dev mailing list | <cocoa-dev...>
    > Help/Unsubscribe/Archives:
    > http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    > Do not post admin requests to the list. They will be ignored.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Sunday, October 26, 2003, at 11:28  AM, Jonathan Wight wrote:

    >> From: Aaron Hillegass <info...>
    >> Date: Sun, 26 Oct 2003 09:42:15 -0500
    >> Subject: The Problems with NSController
    >>
    >> If good demos is the goal, NSController is sufficient, but if Apple is
    >> serious about the enterprise, they should take a long, hard look at
    >> this poorly thought-out mechanism and yank NSController. They could
    >> replace it with something more like EOF. Heck, they could just
    >> recompile the old Objective-C EOF source code.
    >>
    >> These are harsh words, but someone should have stopped this train a
    >> long time ago. The best I can do now is tell you not to get on.
    >
    > Your argument to me sounds like "if it isn't EOF, it sucks". I've been
    > using
    > NSController & co for a while now and it works for me (despite some
    > problems
    > I'm happy to put down to 'learning curve').
    >
    > The net effect is that NSController reduces the number of lines of
    > code in
    > my projects and that makes them easier to maintain and extend. I don't
    > really care whether it "hacks the runtime system", or if Apple isn't
    > using
    > NSController in their projects (yet). Some of your points have merit
    > (like
    > missing undo support and private APIs) but quite frankly this kind of
    > scare
    > mongering isn't particularly useful.

    Considering the amount of time Aaron has been working with these
    frameworks, you should take a little more time before accusing him of
    FUD. It's not like he has some competing product to sell. He's staked
    his career on this stuff and so far has been nothing but a supporter in
    the Cocoa community.
    >
    > To me - the biggest problem with the NSController technology is that
    > it's
    > 10.3 and up only.

    I have to say that it is clearly a kind of hostage-taking tactic on
    Apple's part, considering the ease with which they could patch earlier
    versions of the operating system, and certainly Jaguar. I'd like to see
    them for once demonstrate the fantastic simplicity of their own bundle
    design and release new versions of the Cocoa frameworks for Jaguar.

    Then again, I'm happy with what exists now. Whatever this NSController
    class does, someone else (maybe even me) can probably implement
    something as good or better, given time. However I would like even
    better if I could be proved wrong about Aaron's not having a better
    product. If he or someone else could replace EOF with a new product,
    that would be, in my opinion, the best strategy. I have just recently
    been reading up on the origins of Objective-C and the concept of
    general purpose components, and I have to say that it seems as though
    the real power of objects in the marketplace has never been realized.
    "Not built here" syndrome seems to be alive and well (even in the Open
    Source community), scattered exceptions aside.

    I guess everyone's still worried about Apple undercutting them. Seems
    that Operating Systems vendors are still the number one obstacle to
    software innovation. Not a happy situation.

    ASIDE: did anyone else note that Apple has got a rotational slider in
    the Font Panel similar to the one from Jiiva?

    --
    Brent Gulanowski                <brentg...>
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • I tend to agree with Aaron: I'd rather have EOF for Cocoa desktop apps.

    When I first started working with NSController, I found that some of
    Apple's examples didn't work.
    My first thought was, "This will all settle out when Panther
    stabilizes."
    But with 7B85, some trouble remains.
    And I'm experiencing trouble with Undo.
    (See my To Many example for Panther on my .Mac home page.)

    However, I would argue that a simple recompilation of EOF is not enough
    anymore.
    A new version of EOF would include a version of EOModeler that would
    also do what Suite Modeler does.
    (The name "Suite Modeler" was intended as a play on EOModeler.)

    The new on-line docs for the Controller layer stress E-R modeling.
    http://developer.apple.com/documentation/Cocoa/Conceptual/
    ControllerLayer/index.html
    Suite Modeler's On-line Help does, too.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • Le dimanche, 26 oct 2003, ` 15:42 Europe/Paris, Aaron Hillegass a icrit
    :
    >
    > 5.     It relies on unsavory hacks to the runtime system. For a
    > controller to know about changes to a model object, your accessor
    > methods need to notify it of the change. In EOF, the developer added a
    > call to [self willChange] to each set method in his model objects.
    > NSController (which doesn't trust you to do this) replaces your class
    > with a secret subclass that does the "right" thing.
    >
    >
    Could you (or anyone else) elaborate on this? I just don't understand
    the "magic" of Key-Value Observing: is there a huge performance penalty
    for that?

    > 3.     It has no support for undo. EOF automatically registered all
    > edits, inserts, and deletes with the undo manager.
    >
    Then, what's the recommended way to support undo with NSControllers?

    Thanks,

    Thomas Lachand-Robert
    ********************** <tlr...>
    << Et le chemin est long du projet ` la chose. >> Molihre, Tartuffe.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • So, if I am to understand you correctly, what you are saying is to
    *not* use NSController *at all*?

    Thanks,

    James

    At 9:42 AM -0500 10/26/03, Aaron Hillegass wrote:
    > While working on the second edition of "Cocoa Programming for Mac OS
    > X," I have spent a good chunk of time working with NSController and
    > the bindings mechanism. And I have bad news: they are poorly
    > designed and poorly implemented. I sincerely hope that this
    > technique is deprecated because it will become embarrassment for
    > Apple and the entire Cocoa community.
    >
    > History first: NeXT used to compete in the client-server market
    > against products like PowerBuilder. Minimizing the glue code
    > necessary to write applications that displayed tables of data was
    > very important. So we developed the Enterprise Object Framework
    > (EOF).
    >
    > EOF had an NSController-like mechanism that used a class called
    > NSAssociation. NSAssociation objects worked like the bindings
    > mechanism -- they were a smart link between the controller and the
    > user interface object.
    >
    > People loved EOF. I don't know how many times I heard the following:
    > "I used to use PowerBuilder, but it made 90% of the application easy
    > to write and 10% impossible." NSAssociation and careful use of
    > delegation made EOF easy to extend.
    >
    > NSController and the binding mechanism suffers from
    > PowerBuilder-like shortcomings: As long as you do exactly what the
    > designer planned, it is quite convenient, but the moment you wander
    > off this narrow trail, misery ensues.
    >
    > Here are the basic design flaws that plague NSController and the
    > bindings mechanism:
    >
    > 1.     It eschews the delegation design pattern. This makes
    > it difficult to extend and inconsistent with the rest of Cocoa.
    >
    > 2.     It uses a lot of private APIs. NSAssociation has been
    > replaced by NSBinder and NSBinderAdaptor. NSAssociation, however,
    > was public and easily subclassed. NSBinder and NSBinderAdaptor are
    > private and undocumented. Altering the default behavior of the
    > bindings is impossible.
    >
    > 3.     It has no support for undo. EOF automatically
    > registered all edits, inserts, and deletes with the undo manager.
    >
    > 4.     It has no support for relational databases. EOF could
    > bundle all those edits into tidy SQL statements and put them into a
    > relational database for you. This was made possible by a carefully
    > defined data source protocol. You could easily create your own data
    > sources and slip them under the controller.
    >
    > 5.     It relies on unsavory hacks to the runtime system.
    > For a controller to know about changes to a model object, your
    > accessor methods need to notify it of the change. In EOF, the
    > developer added a call to [self willChange] to each set method in
    > his model objects. NSController (which doesn't trust you to do this)
    > replaces your class with a secret subclass that does the "right"
    > thing.
    >
    > 6.     It was created in a vacuum and rushed to market. No
    > one at Apple has ever created a realistic application with
    > NSController.  The design,  the implementation, and the
    > documentation would all be better if someone at Apple had been
    > required to actually use NSController.
    >
    > (Note that this is not a list of bugs -- those will disappear in
    > time -- but only basic design errors.)
    >
    > I have met a few people who claimed that EOF was hard to use. These
    > people, regardless of what was written their business cards, were
    > not programmers. I'm glad that they decided to work in PowerBuilder
    > or Visual Basic -- I'm certain that regardless of the tool they
    > chose, these people never produced an application of any worth. EOF
    > and Cocoa were designed to give real power to real programmers.
    > NSController and the bindings mechanism were designed to give power
    > to people doing demos.
    >
    > If good demos is the goal, NSController is sufficient, but if Apple
    > is serious about the enterprise, they should take a long, hard look
    > at this poorly thought-out mechanism and yank NSController. They
    > could replace it with something more like EOF. Heck, they could just
    > recompile the old Objective-C EOF source code.
    >
    > These are harsh words, but someone should have stopped this train a
    > long time ago. The best I can do now is tell you not to get on.
    >
    > Sincerely,
    > Aaron Hillegass
    >
    > (To prevent a bunch of emails, let me mention that you will not be
    > able to buy the second edition of "Cocoa Programming for Mac OS X"
    > for many months. If you want a copy of the current draft, you should
    > come to class at the Big Nerd Ranch. We are offering a class Nov 10
    > - 14 in Atlanta.)
    >
    > (I've put a copy of this on the Big Nerd Ranch website:
    > http://www.bignerdranch.com/Resources/nscontroller.html
    > )
    > _______________________________________________
    > cocoa-dev mailing list | <cocoa-dev...>
    > Help/Unsubscribe/Archives:
    > http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    > Do not post admin requests to the list. They will be ignored.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Oct 26, 2003, at 11:18 AM, Francisco J. Bido wrote:
    > Experience programmers don't care about writing a few lines of extra
    > code, if it means more control.

    Experienced programmers know that every line of code is an opportunity
    for more bugs, and prefer to minimize the amount of unnecessary code to
    accomplish a particular task.

    NSController is very useful for this.

      -- Chris

    --
    Chris Hanson, bDistributed.com, Inc.  |  Email: <cmh...>
    Custom Mac OS X Development          |  Phone: +1-847-372-3955
    http://bdistributed.com/              |  Fax:  +1-847-589-3738
    http://bdistributed.com/Articles/    |  Personal Email: <cmh...>
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • I got this useful information from Shaun Wexler to make the first demo
    in the NSController tutorial to work. See below. The lack of Undo
    support is a little scary. Is there a way to easily add it? I suppose
    you could do the registration with the Undo Manager in the setters,
    like we used to, as in:

    [[[self undoManager] prepareWithInvocationTarget:self]
    setDollarsToConvert:value];

    Right?

    > I wonder if you can do me a favor and look at the tutorial in:
    >
    > /Developer/Documentation/Cocoa/Conceptual/ControllerLayer/Tasks/
    > ccwithbindings.html
    >
    > Can you tell me if it is missing any steps? How does the controller
    > know to update the amountInOtherCurrency view when the values for
    > dollarsToConvert or exchangeRate change?

    I see no NSValueTransformer, nor any bindings to perform the update, so
    you'll need to choose one of several methods, the easiest of which is:

    + (void)initialize
    {
    [self setKeys:[NSArray arrayWithObjects:@"dollarsToConvert",
    @"exchangeRate", nil]
    triggerChangeNotificationsForDependentKey:@"amountInOtherCurrency"];
    }

    ...which does the equivalent of wrapping each setter method's code like
    this:

    - (void)setDollarsToConvert:(double)dollars
    {
    [self willChangeValueForKey:@"amountInOtherCurrency"];
          dollarsToConvert = dollars;
    [self didChangeValueForKey:@"amountInOtherCurrency"];
    }

    - (void)setExchangeRate:(double)rate
    {
    [self willChangeValueForKey:@"amountInOtherCurrency"];
          exchangeRate = rate;
    [self didChangeValueForKey:@"amountInOtherCurrency"];
    }

    On Oct 26, 2003, at 12:52 PM, Don Briggs wrote:

    > When I first started working with NSController, I found that some of
    > Apple's examples didn't work.
    > My first thought was, "This will all settle out when Panther
    > stabilizes."
    > But with 7B85, some trouble remains.
    > And I'm experiencing trouble with Undo.
    > (See my To Many example for Panther on my .Mac home page.)

    --
    Mike Nowak
    Work: http://healthmedia.umich.edu/
    Personal: http://snackdog.org/

    "Better out than in."

    [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Sunday, October 26, 2003, at 03:09  PM, Chris Hanson wrote:

    > On Oct 26, 2003, at 11:18 AM, Francisco J. Bido wrote:
    >> Experience programmers don't care about writing a few lines of extra
    >> code, if it means more control.
    >
    > Experienced programmers know that every line of code is an opportunity
    > for more bugs, and prefer to minimize the amount of unnecessary code
    > to accomplish a particular task.
    >
    > NSController is very useful for this.

    I'm sorry but that is specious, since writing less code is an attribute
    of OOP itself, if you use it right. NSController is just another class,
    which is either written well or written poorly. If the savings in
    NSController are so magical, I suspect that any good Cocoa developer
    has already abstracted similar functionality. Apple does not have a
    monopoly on software engineering principles, whether they built the OS
    or no.

    What you are really saying is that it saves lazy programmers the work
    of doing their own software engineering. Just think how much coding I
    would not have to do if I were not a programmer at all!

    --
    Brent Gulanowski                <brentgulanowski...>
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • > From: Mike Nowak <mnowak...>
    > Date: Sun, 26 Oct 2003 15:12:25 -0500
    > To: Cocoa-Dev Mail <cocoa-dev...>
    > Subject: Re: The Problems with NSController (Undo)
    >
    > I got this useful information from Shaun Wexler to make the first demo
    > in the NSController tutorial to work. See below. The lack of Undo
    > support is a little scary. Is there a way to easily add it? I suppose
    > you could do the registration with the Undo Manager in the setters,
    > like we used to, as in:
    >
    > [[[self undoManager] prepareWithInvocationTarget:self]
    > setDollarsToConvert:value];

    I'm doing undo handling in my "observeValueForKeyPath" delegate method. In
    my document creation I'm registering for NSKeyValueObservation:

    [self addObserver:self forKeyPath:@"waypoints"
    options:NSKeyValueObservingOptionOld context:NULL];

    And then I have my delegate method (snippet):

    - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
    change:(NSDictionary *)change context:(void *)context
    {
    if ([keyPath isEqual:@"waypoints"])
        {
        [[self undoManager] registerUndoWithTarget:self
    selector:@selector(setWaypoints:) object:[change
    objectForKey:NSKeyValueChangeOldKey]];
        }
    }

    I've only just started with this method so it might not be the best way. But
    this method is really simple. So while NSController doesn't provide
    automatic undo support it is still pretty simple.

        Jon.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • >> Experienced programmers know that every line of code is an opportunity
    >> for more bugs, and prefer to minimize the amount of unnecessary code
    >> to accomplish a particular task.
    >>
    >> NSController is very useful for this.
    >
    > I'm sorry but that is specious, since writing less code is an attribute
    > of OOP itself, if you use it right. NSController is just another class,
    > which is either written well or written poorly. If the savings in
    > NSController are so magical, I suspect that any good Cocoa developer
    > has already abstracted similar functionality. Apple does not have a
    > monopoly on software engineering principles, whether they built the OS
    > or no.

    It's not magical. Interface Builder is effectively doing more of the work
    for you. Just like how Interface Builder removes some of the tedious parts
    of UI creation it also is now capable of removing some of the tedious parts
    of UI logic too.

    > What you are really saying is that it saves lazy programmers the work
    > of doing their own software engineering. Just think how much coding I
    > would not have to do if I were not a programmer at all!

    You can use the same argument against any vendor supplied API. Heck - _real_
    programmers code in machine code anyway, everyone else is just lazy! ;-)

        Jon.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Sunday, October 26, 2003, at 08:45  pm, Brent Gulanowski wrote:

    > On Sunday, October 26, 2003, at 03:09  PM, Chris Hanson wrote:
    >
    >> Experienced programmers know that every line of code is an
    >> opportunity for more bugs, and prefer to minimize the amount of
    >> unnecessary code to accomplish a particular task.

    [snip]

    > What you are really saying is that it saves lazy programmers the work
    > of doing their own software engineering. Just think how much coding I
    > would not have to do if I were not a programmer at all!

    No, I think Chris means that NSController is a generic, reusable class
    (although as Aaron says, it isn't as reusable as he'd like), rather
    than the task-specific class that most programmers would write for this
    purpose.  I tend to agree with the comment about bugs, also.  If you
    were writing the code for this yourself, OK, you might choose to write
    it in a similar way to NSController, and have generic support (although
    it'd be hard to integrate with Interface Builder, since you aren't
    Apple)... but Apple have the advantage in terms of bug detection and
    bug fixing; not only have they (reportedly) spent somewhere in the
    region of $14m developing (and presumably testing) Panther, but they
    also have bug reports from all of us.  If I, as a lone developer,
    implemented similar functionality, just for my applications, I wouldn't
    get as many good bug reports as they will.

    In programming, laziness is a virtue ;-)  Less code to do the same task
    is almost always better, whether in terms of performance, probability
    of bugs, ease of maintenance, robustness to change, or even just time
    to market.  There are, of course, exceptions (algorithmic
    optimisations, for example, often result in more code rather than
    less), but in my experience they are just that... exceptions.

    Kind regards,

    Alastair.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Oct 26, 2003, at 12:45 PM, Brent Gulanowski wrote:

    > On Sunday, October 26, 2003, at 03:09  PM, Chris Hanson wrote:
    >
    >> On Oct 26, 2003, at 11:18 AM, Francisco J. Bido wrote:
    >>> Experience programmers don't care about writing a few lines of extra
    >>> code, if it means more control.
    >>
    >> Experienced programmers know that every line of code is an
    >> opportunity for more bugs, and prefer to minimize the amount of
    >> unnecessary code to accomplish a particular task.
    >>
    >> NSController is very useful for this.
    >
    > I'm sorry but that is specious, since writing less code is an
    > attribute of OOP itself, if you use it right. NSController is just
    > another class, which is either written well or written poorly. If the
    > savings in NSController are so magical, I suspect that any good Cocoa
    > developer has already abstracted similar functionality. Apple does not
    > have a monopoly on software engineering principles, whether they built
    > the OS or no.

    The following is not necessarily advocating use of NSController (which
    I have yet to make up my mind about) but I have to say my jaw just
    about dropped when I read the above. Whatever arguments can be made
    against NSController, I can't believe this is legitimately one of them.
    Let me repeat what you just said, substituting "X" for NSController:

    > I'm sorry but that is specious, since writing less code is an
    > attribute of OOP itself, if you use it right. X is just another class,
    > which is either written well or written poorly. If the savings in X
    > are so magical, I suspect that any good Cocoa developer has already
    > abstracted similar functionality. Apple does not have a monopoly on
    > software engineering principles, whether they built the OS or no.

    This seems to argue that Apple can just stop making ANY improvements to
    Cocoa, at least anything specifically aimed at reducing the amount of
    coding. There is no way they can make any improvements in this area
    because if it was in anyway worthwhile, any competent developer has
    already done it! Assuming you consider yourself a "good Cocoa
    developer" this means if I look at your code i can find every possible
    useful abstraction that would save coding!

    > What you are really saying is that it saves lazy programmers the work
    > of doing their own software engineering. Just think how much coding I
    > would not have to do if I were not a programmer at all!

    The more of my software engineering they can do the better. I think the
    controversy here is whether it is _good_ software engineering, but if
    it is, I say bring it on!

    - Dennis D.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • But in this case you are talking about very easy code -I wrote that  in
    my post somewhere.  From my perspective, the way to write better code
    is not to necessarily minimize the number of lines of code (although
    that definitely helps sometimes) but to make the ones that are proven
    to work well (even if they're many of them) reusable.

    It would be interesting to see what kinds of non-trivial things you can
    do better with NSController than with the usual Cocoa MVC
    implementation.

    -Francisco

    On Oct 26, 2003, at 2:09 PM, Chris Hanson wrote:

    > On Oct 26, 2003, at 11:18 AM, Francisco J. Bido wrote:
    >> Experience programmers don't care about writing a few lines of extra
    >> code, if it means more control.
    >
    > Experienced programmers know that every line of code is an opportunity
    > for more bugs, and prefer to minimize the amount of unnecessary code
    > to accomplish a particular task.
    >
    > NSController is very useful for this.
    >
    > -- Chris
    >
    > --
    > Chris Hanson, bDistributed.com, Inc.  |  Email: <cmh...>
    > Custom Mac OS X Development          |  Phone: +1-847-372-3955
    > http://bdistributed.com/              |  Fax:  +1-847-589-3738
    > http://bdistributed.com/Articles/    |  Personal Email: <cmh...>
    > _______________________________________________
    > cocoa-dev mailing list | <cocoa-dev...>
    > Help/Unsubscribe/Archives:
    > http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    > Do not post admin requests to the list. They will be ignored.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Sunday, October 26, 2003, at 06:19  PM, Dennis C.De Mars wrote:

    >
    > On Oct 26, 2003, at 12:45 PM, Brent Gulanowski wrote:
    >
    >> On Sunday, October 26, 2003, at 03:09  PM, Chris Hanson wrote:
    >>
    >>> On Oct 26, 2003, at 11:18 AM, Francisco J. Bido wrote:
    >>>> Experience programmers don't care about writing a few lines of
    >>>> extra code, if it means more control.
    >>>
    >>> Experienced programmers know that every line of code is an
    >>> opportunity for more bugs, and prefer to minimize the amount of
    >>> unnecessary code to accomplish a particular task.
    >>>
    >>> NSController is very useful for this.
    >>
    >> I'm sorry but that is specious, since writing less code is an
    >> attribute of OOP itself, if you use it right. NSController is just
    >> another class, which is either written well or written poorly. If the
    >> savings in NSController are so magical, I suspect that any good Cocoa
    >> developer has already abstracted similar functionality. Apple does
    >> not have a monopoly on software engineering principles, whether they
    >> built the OS or no.
    >
    > The following is not necessarily advocating use of NSController (which
    > I have yet to make up my mind about) but I have to say my jaw just
    > about dropped when I read the above. Whatever arguments can be made
    > against NSController, I can't believe this is legitimately one of
    > them. Let me repeat what you just said, substituting "X" for
    > NSController:
    >
    >> I'm sorry but that is specious, since writing less code is an
    >> attribute of OOP itself, if you use it right. X is just another
    >> class, which is either written well or written poorly. If the savings
    >> in X are so magical, I suspect that any good Cocoa developer has
    >> already abstracted similar functionality. Apple does not have a
    >> monopoly on software engineering principles, whether they built the
    >> OS or no.
    >
    > This seems to argue that Apple can just stop making ANY improvements
    > to Cocoa, at least anything specifically aimed at reducing the amount
    > of coding. There is no way they can make any improvements in this area
    > because if it was in anyway worthwhile, any competent developer has
    > already done it! Assuming you consider yourself a "good Cocoa
    > developer" this means if I look at your code i can find every possible
    > useful abstraction that would save coding!

    What? Nary a word of it. You cannot say my words argue the opposite of
    something just because they argue against that thing. Just because
    something is not one does not make it zero. I might prefer -Pi or a
    fish or the colour blue. This is not a binary state. You've been
    programming too long or something.

    The OP attributed the quality of code re-use to NSController
    specifically as an argument for it, and I said that it was a moot point
    because that quality is already understood to belong to all properly
    designed OO classes. It's like saying that blue whales are better than
    other whales because they are mammals. All whales are mammals. If blue
    whales are really better than other whales, I expect better arguments
    for why. The same here.

    I've read a number of powerful arguments why it is bad, however, and
    added my own on philosophical grounds.
    >
    >> What you are really saying is that it saves lazy programmers the work
    >> of doing their own software engineering. Just think how much coding I
    >> would not have to do if I were not a programmer at all!
    >
    > The more of my software engineering they can do the better. I think
    > the controversy here is whether it is _good_ software engineering, but
    > if it is, I say bring it on!

    You state the obvious, sir.

    --
    Brent Gulanowski                <brentgulanowski...>
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Monday, October 27, 2003, at 12:07  am, Brent Gulanowski wrote:

    > The OP attributed the quality of code re-use to NSController
    > specifically as an argument for it, and I said that it was a moot
    > point because that quality is already understood to belong to all
    > properly designed OO classes.

    But it often doesn't to controller classes, because they are typically
    very task-specific (i.e. they are often where the application-specific
    glue-code ends-up).  I think it would be unfair to claim that such
    classes were "not properly designed", although they are certainly not
    generally intended to be widely re-used.

    NSController is one attempt at creating a generic controller whose
    behaviour can be customised without writing code, and on that basis
    should be applauded as a worthwhile exercise.  It might not be as good
    as EOF, there might be problems with it, but it is potentially still a
    good thing to have (I haven't used it enough yet to make my mind up as
    to whether *I* like it, but I certainly like the *idea* of it).

    Kind regards,

    Alastair.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • Am Montag, 27.10.03 um 00:43 Uhr schrieb Francisco J. Bido:

    > It would be interesting to see what kinds of non-trivial things you
    > can do better with NSController than with the usual Cocoa MVC
    > implementation.

    Depends on what you mean by "better". I for myself was thinking about
    something like NSController before, when I got weary of writing methods
    like updateThis, updateThat for my preferences Window(s).

    Only problem was - I would either have had to build some IB-Plugin or
    define the actual bindings in some kind of seperate text/data file. The
    first way seemed too much work, the second not enough different from
    writing regular source code.

    So I'm quite happy that Apple came up with exactly the solution I was
    thinking about. I'm not so happy, that Aaron suggests that the
    implementation of said solution is inherently flawed. I'm still waiting
    for my Panther package to arrive, so I've not had the opportunity to
    work with NSController yet. I'll probably do that later today, and I
    hope there will be ways to extend the concept so that Aaron's doubts
    will prove unwarranted.

    On a different note (*), I think it would have been a good idea for
    Apple to work with the community instead of doing everything on their
    own. Might have avoided some problems - be they real or only perceived.

    bye.  Andreas.

    (*) I'm not a native english speaker. Is that a correct use of this
    phrase?
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Oct 26, 2003, at 11:28 AM, Jonathan Wight wrote:

    >> From: Aaron Hillegass <info...>
    >> Date: Sun, 26 Oct 2003 09:42:15 -0500
    >> Subject: The Problems with NSController
    >>
    >> If good demos is the goal, NSController is sufficient, but if Apple is
    >> serious about the enterprise, they should take a long, hard look at
    >> this poorly thought-out mechanism and yank NSController. They could
    >> replace it with something more like EOF. Heck, they could just
    >> recompile the old Objective-C EOF source code.
    >>
    >> These are harsh words, but someone should have stopped this train a
    >> long time ago. The best I can do now is tell you not to get on.
    >
    > Your argument to me sounds like "if it isn't EOF, it sucks". I've been
    > using
    > NSController & co for a while now and it works for me (despite some
    > problems
    > I'm happy to put down to 'learning curve').

    Based on my reading of the ControlLayer doc, I really think it's
    significantly more complex than EOF was. EOF's architecture was
    much cleaner and easier to explain, which, I think, is a sign of
    a good design. EOF got hairy at some lower levels, but at the IB
    level, it was connect-the-objects and drag and drop.

    > The net effect is that NSController reduces the number of lines of
    > code in
    > my projects and that makes them easier to maintain and extend. I don't
    > really care whether it "hacks the runtime system", or if Apple isn't
    > using
    > NSController in their projects (yet). Some of your points have merit
    > (like
    > missing undo support and private APIs) but quite frankly this kind of
    > scare
    > mongering isn't particularly useful.

    The problem is that people have spent hundreds or thousands of hours
    developing real applications with EOF. Applications like financial
    trading systems. And having done that, I'm pretty sure it would be
    significantly harder with NSController.

    What's baffling is that it's almost like they didn't even consider
    EOF at all. I mean, wasn't EOF the whole reason Key-Value Coding
    was added in the first place? The AppKit and Foundation were extended
    for EOF, and now EOF's gone, and they're adding things again to support
    NSController.

    It's not like they don't have the source code. An institutional memory
    is a terrible thing to waste.

    I don't get it.

    All that said, it's nice to have something to remove the drudgery of
    MVC, at least in smaller apps.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Oct 26, 2003, at 6:43 PM, Francisco J. Bido wrote:

    > But in this case you are talking about very easy code -I wrote that
    > in my post somewhere.  From my perspective, the way to write better
    > code is not to necessarily minimize the number of lines of code
    > (although that definitely helps sometimes) but to make the ones that
    > are proven to work well (even if they're many of them) reusable.
    >

    But they aren't reusable. They don't really contribute anything
    meaningful to your application, and they aren't reusable. It's almost
    always just busy work,
    often required if you're using the MVC pattern to decouple the Model
    from the View.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • > NSAssociation and careful use of delegation made EOF easy to extend.

    It seems likely that, particularly for this release, the Bindings
    weren't designed for "easy extension". Delegation (the AppKit way, with
    informal protocols) can always be added later without too much trouble.

    > 1.     It eschews the delegation design pattern. This makes it
    > difficult to extend and inconsistent with the rest of Cocoa.
    > 2.     It uses a lot of private APIs. NSAssociation has been replaced
    > by NSBinder and NSBinderAdaptor. NSAssociation, however, was public
    > and easily subclassed. NSBinder and NSBinderAdaptor are private and
    > undocumented. Altering the default behavior of the bindings is
    > impossible.

    This is true, but it may be because of time-to-market concerns, or
    concerns about overwhelming (new) users with more possibilitiies than
    many of them need? EOF had a pretty good idea where they were going and
    what their target audience was. It could be that Apple put out the
    basic structure, and are looking to see where the developers want it to
    go before adding the code. Once new API or behavior is added to the
    'Kits, it's mighty hard to remove, so I can see Apple being very
    careful about it. Backward compatibility is much more important to
    Apple than it was to NeXT (for obvious reasons, I think).

    > 3.     It has no support for undo. EOF automatically registered all
    > edits, inserts, and deletes with the undo manager.

    Of course, the objects that EOF managed were controlled by the EOModel,
    which provided a great deal of meta-information about the objects (such
    as which attributes are important, etc). I think perhaps requiring an
    EOModel for a basic controller object is a bit more complex than
    strictly necessary.

    In the default Bindings case, where the changes are "magic" it might
    get messy. I assume that if you do things manually
    (automaticallyNotifiesObserversForKey && willChangeValueForKey) you can
    also hook up to the undo manager at the same time.

    > 4.     It has no support for relational databases. EOF could bundle
    > all those edits into tidy SQL statements and put them into a
    > relational database for you. This was made possible by a carefully
    > defined data source protocol. You could easily create your own data
    > sources and slip them under the controller.

    This seems to be unrelated to the design or implementation of the
    controller - it's just a need for object persistance. The Bindings are,
    conceptually, virtually unrelated to persistance. I think quite a few
    developers can use the Bindings just as they are now. I don't argue
    that the whole EOF stack would be great, but again, that requires
    EOModeler, an adaptor, some sort of database (embedded, system-wide, or
    provided by the developer), etc. I'm not convinced that Apple wants to
    just release all that to the public and suddenly be committed to make
    it work forever.

    There is also a bright side to this separation - it means that you
    don't have to have persistance to make this all work. One of EOF's
    shortcomings in my experience was trying to get EOF to do object
    management without persistance - since it often assumed that there was
    a database somewhere down there, there was much pain involved if there
    wasn't. I'd like the idea of Apple bringing back all the technology
    that made up EOF, but independant in a way that you only had to work
    with the bits that you were actually going to use.

    > 5.     It relies on unsavory hacks to the runtime system. For a
    > controller to know about changes to a model object, your accessor
    > methods need to notify it of the change. In EOF, the developer added a
    > call to [self willChange] to each set method in his model objects.
    > NSController (which doesn't trust you to do this) replaces your class
    > with a secret subclass that does the "right" thing.

    I'd expect AppKit/Foundation/CoreFoundation to be rife with unsavory
    hacks to the runtime system. That's the point of AppKit/Foundation now,
    really - do all the groddy stuff so we don't have to :)

    In any case, I kind of like the Bindings way better - no more doing the
    work by hand (or doing it through EOModeler, which is again overkill
    for many many use cases). And it's overrideable if you so desire.

    > 6.     It was created in a vacuum and rushed to market. No one at
    > Apple has ever created a realistic application with NSController.
    > The design,  the implementation, and the documentation would all be
    > better if someone at Apple had been required to actually use
    > NSController.

    The documentation always lags - it's just a way of life, I think :)

    > (Note that this is not a list of bugs -- those will disappear in time
    > -- but only basic design errors.)

    I don't really agree. I think the Bindings were a very focused addition
    to Cocoa. I understand your frustration that it is so _very_ focused
    (given its EOF heritage) but at the same time, I think it's more useful
    to judge it by what it brings rather than what it _could_ have brought
    if Apple had imported the EOF stack wholesale.

    > I have met a few people who claimed that EOF was hard to use. These
    > people, regardless of what was written their business cards, were not
    > programmers. I'm glad that they decided to work in PowerBuilder or
    > Visual Basic -- I'm certain that regardless of the tool they chose,
    > these people never produced an application of any worth.

    I'd have to hope that you were joking here. People write real programs
    in PowerBuilder or Visual Basic. They make money off of them, and they
    do what they are supposed to. EOF solves a specific set of problems,
    and it does it quite well, but it also has quite a steep learning
    curve, and quite a lot of quirky behaviors to figure out. What I want
    from Apple is something as easy to use as PowerBuilder or Visual Basic,
    but as powerful as Cocoa is now. (I think the
    DirectToWeb/DirectToJavaClient technology from Apple's WebObjects as a
    good example of something that is simple to use, but still quite
    powerful).

    > EOF and Cocoa were designed to give real power to real programmers.
    > NSController and the bindings mechanism were designed to give power to
    > people doing demos.

    Again, it seems almost insulting. I have an app where the app
    functionality tool about an hour to write (mostly looking up
    documentation and deciding how the UI would look). The preferences
    panel and associated code took 3 hours to write - time which could have
    been cut probably by 2/3s by using the Bindings, which enhanced
    functionality as a bonus.

    > If good demos is the goal, NSController is sufficient, but if Apple is
    > serious about the enterprise, they should take a long, hard look at
    > this poorly thought-out mechanism and yank NSController. They could
    > replace it with something more like EOF. Heck, they could just
    > recompile the old Objective-C EOF source code.

    The Bindings seem aimed squarely at the desktop market. Looking at them
    with Enterprise colored glasses on, I can certainly say they are poorly
    designed, but I have a hard time saying that when looking at them with
    Desktop-app colored glasses on. From that point of view, they seem
    quite useful (not the garden of eden for sure - something _like_ EOF
    would be a godsend), but certainly not the train wreck you paint them
    to be.

    Karl

    --

    That which does not kill me had better run pretty damn fast.

    Homepage:
          http://homepage.mac.com/khsu/index.html
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Oct 27, 2003, at 12:44 AM, Hsu wrote:
    >

    >> 1.     It eschews the delegation design pattern. This makes it
    >> difficult to extend and inconsistent with the rest of Cocoa.
    >> 2.     It uses a lot of private APIs. NSAssociation has been replaced
    >> by NSBinder and NSBinderAdaptor. NSAssociation, however, was public
    >> and easily subclassed. NSBinder and NSBinderAdaptor are private and
    >> undocumented. Altering the default behavior of the bindings is
    >> impossible.
    >
    > This is true, but it may be because of time-to-market concerns, or
    > concerns about overwhelming (new) users with more possibilitiies than
    > many of them need? EOF had a pretty good idea where they were going
    > and what their target audience was. It could be that Apple put out the
    > basic structure, and are looking to see where the developers want it
    > to go before adding the code. Once new API or behavior is added to the
    > 'Kits, it's mighty hard to remove, so I can see Apple being very
    > careful about it. Backward compatibility is much more important to
    > Apple than it was to NeXT (for obvious reasons, I think).

    I don't think that's true about NeXT. After all, EOF and Foundation were
    initially released as an optional add-on to NeXTSTEP 3.2. They didn't
    add them during
    an epochal compatibility break like 10.3. EOF and Foundation added
    functionality
    without requiring wholesale replacement of the AppKit, or breaking 3.x
    programs.

    It's true that it's hard to remove API. Which makes me wonder even more
    why the
    NSController is the way it is.

    >
    >> 3.     It has no support for undo. EOF automatically registered all
    >> edits, inserts, and deletes with the undo manager.
    >
    > Of course, the objects that EOF managed were controlled by the
    > EOModel, which provided a great deal of meta-information about the
    > objects (such as which attributes are important, etc). I think perhaps
    > requiring an EOModel for a basic controller object is a bit more
    > complex than strictly necessary.

    Are you thinking of database undo/rollback? I can't see how the Model
    has anything to do with
    Appkit-level Undo. Appkit-level undo applies to all attributes, even
    ones that are
    not important in the database schema. The Model would influence
    rollback behavior
    and referential integrity, which aren't really at issue here.

    >> 5.     It relies on unsavory hacks to the runtime system. For a
    >> controller to know about changes to a model object, your accessor
    >> methods need to notify it of the change. In EOF, the developer added
    >> a call to [self willChange] to each set method in his model objects.
    >> NSController (which doesn't trust you to do this) replaces your class
    >> with a secret subclass that does the "right" thing.
    >
    > I'd expect AppKit/Foundation/CoreFoundation to be rife with unsavory
    > hacks to the runtime system. That's the point of AppKit/Foundation
    > now, really - do all the groddy stuff so we don't have to :)
    >
    > In any case, I kind of like the Bindings way better - no more doing
    > the work by hand (or doing it through EOModeler, which is again
    > overkill for many many use cases). And it's overrideable if you so
    > desire.

    EOModeler was nice because it generated code. ;^) And you could drag
    things into IB,
    so IB would know about attributes 'n stuff, automagically.

    We need NSModeler, I think. Forget about the SQL stuff, just a nice GUI
    tool
    for creating skeleton model classes, which would generate source and be
    integrated with IB.
    >

    >
    >> (Note that this is not a list of bugs -- those will disappear in time
    >> -- but only basic design errors.)
    >
    > I don't really agree. I think the Bindings were a very focused
    > addition to Cocoa. I understand your frustration that it is so _very_
    > focused (given its EOF heritage) but at the same time, I think it's
    > more useful to judge it by what it brings rather than what it _could_
    > have brought if Apple had imported the EOF stack wholesale.

    They're definitely an improvement, and it sucks to complain about
    something people have been asking for, but I have to wonder about why
    they seemingly threw out so much. It's
    almost like they hadn't used EOF. (I haven't used Java EOF yet. Is
    NSController like
    that at all?)

    >> If good demos is the goal, NSController is sufficient, but if Apple
    >> is serious about the enterprise, they should take a long, hard look
    >> at this poorly thought-out mechanism and yank NSController. They
    >> could replace it with something more like EOF. Heck, they could just
    >> recompile the old Objective-C EOF source code.
    >
    > The Bindings seem aimed squarely at the desktop market. Looking at
    > them with Enterprise colored glasses on, I can certainly say they are
    > poorly designed, but I have a hard time saying that when looking at
    > them with Desktop-app colored glasses on. From that point of view,
    > they seem quite useful (not the garden of eden for sure - something
    > _like_ EOF would be a godsend), but certainly not the train wreck you
    > paint them to be.

    I'm not entirely sure what "Enterprise" has to do with it, since the
    database functionality isn't really at issue. Everything in EOF at the
    UI level would be quite at home
    in 'desktop' applications. And you never know when a customer is going
    to try
    to use your 'desktop' framework to do 'enterprise' work.

    Seems to me that the NSController layer is to EOF's UI layer as DBKit
    was to EOF.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Oct 26, 2003, at 10:22 PM, Jonathan Hendry wrote:

    >> This is true, but it may be because of time-to-market concerns, or
    >> concerns about overwhelming (new) users with more possibilitiies than
    >> many of them need? EOF had a pretty good idea where they were going
    >> and what their target audience was. It could be that Apple put out
    >> the basic structure, and are looking to see where the developers want
    >> it to go before adding the code. Once new API or behavior is added to
    >> the 'Kits, it's mighty hard to remove, so I can see Apple being very
    >> careful about it. Backward compatibility is much more important to
    >> Apple than it was to NeXT (for obvious reasons, I think).
    >
    > I don't think that's true about NeXT. After all, EOF and Foundation
    > were
    > initially released as an optional add-on to NeXTSTEP 3.2. They didn't
    > add them during
    > an epochal compatibility break like 10.3. EOF and Foundation added
    > functionality
    > without requiring wholesale replacement of the AppKit, or breaking 3.x
    > programs.

    The NeXT market was considerably smaller, and consisted (in large part)
    of vertical market applications. This lends itself to maintaining
    source, but not binary compatibility. Current MacOS can't really do
    that (people already get pretty upset at the amount of breakage).

    > It's true that it's hard to remove API. Which makes me wonder even
    > more why the
    > NSController is the way it is.

    What would need to change about the NSController API to fix it (in
    contrast to adding API or changing behavior)?

    >> Of course, the objects that EOF managed were controlled by the
    >> EOModel, which provided a great deal of meta-information about the
    >> objects (such as which attributes are important, etc). I think
    >> perhaps requiring an EOModel for a basic controller object is a bit
    >> more complex than strictly necessary.
    >
    > Are you thinking of database undo/rollback? I can't see how the Model
    > has anything to do with
    > Appkit-level Undo. Appkit-level undo applies to all attributes, even
    > ones that are
    > not important in the database schema. The Model would influence
    > rollback behavior
    > and referential integrity, which aren't really at issue here.

    Do you always want every single attribute change to be registered with
    the Undo manager, all the time? Even so, it seems like this sort of
    automatic undo management could be added in a future release without
    any serious issues, implying that it's not really a fundamental
    architectural flaw in the Bindings.

    >> I'd expect AppKit/Foundation/CoreFoundation to be rife with unsavory
    >> hacks to the runtime system. That's the point of AppKit/Foundation
    >> now, really - do all the groddy stuff so we don't have to :)
    >>
    >> In any case, I kind of like the Bindings way better - no more doing
    >> the work by hand (or doing it through EOModeler, which is again
    >> overkill for many many use cases). And it's overrideable if you so
    >> desire.
    >
    > EOModeler was nice because it generated code. ;^)
    > And you could drag things into IB,
    > so IB would know about attributes 'n stuff, automagically.

    But isn't this a function of having designed your data model in
    EOModeler? Still seems like there is some disconnect between Data Model
    and Controller. They seem different to me - the Bindings are designed
    to address the "Controller" part of MVC (more specifically the VC
    part), not the "Model" part.

    > We need NSModeler, I think. Forget about the SQL stuff, just a nice
    > GUI tool
    > for creating skeleton model classes, which would generate source and be
    > integrated with IB.

    Perhaps they will come later. Their lack now doesn't seem like a
    sweeping architectural flaw in the Bindings, just an area that the
    Bindings don't address. The Bindings bring automatic change management
    without the need for code generation (quite nice) and a strong
    separation from the concept of data persistance (also quite nice).
    (Note: Not to say data persistance wouldn't be welcomed with open arms,
    but at that point you start getting into NSModeler territory).

    >> don't really agree. I think the Bindings were a very focused addition
    >> to Cocoa. I understand your frustration that it is so _very_ focused
    >> (given its EOF heritage) but at the same time, I think it's more
    >> useful to judge it by what it brings rather than what it _could_ have
    >> brought if Apple had imported the EOF stack wholesale.
    >
    > They're definitely an improvement, and it sucks to complain about
    > something people have been asking for, but I have to wonder about why
    > they seemingly threw out so much. It's
    > almost like they hadn't used EOF. (I haven't used Java EOF yet. Is
    > NSController like
    > that at all?)

    I think "they" have used EOF, and are cognizant of it's shortcomings in
    a Desktop sense. EOF is a fairly dense framework for data object
    management and persistance. It was really cool if that was what you
    were doing, but kind of annoying if you only wanted little bits of it.
    Again, I think the idea of breaking up EOF, to make the individual
    parts easier to use by themselves is probably the goal, and a laudable
    one.

    Java EOF is pretty similar to Obj EOF, given the difference in
    languages.

    >> The Bindings seem aimed squarely at the desktop market. Looking at
    >> them with Enterprise colored glasses on, I can certainly say they are
    >> poorly designed, but I have a hard time saying that when looking at
    >> them with Desktop-app colored glasses on. From that point of view,
    >> they seem quite useful (not the garden of eden for sure - something
    >> _like_ EOF would be a godsend), but certainly not the train wreck you
    >> paint them to be.
    >
    > I'm not entirely sure what "Enterprise" has to do with it, since the
    > database functionality isn't really at issue.

    It is, only because Aaron's initial post pointed out the lack of SQL
    generation as a "basic design flaw".

    > Everything in EOF at the UI level would be quite at home
    > in 'desktop' applications. And you never know when a customer is going
    > to try
    > to use your 'desktop' framework to do 'enterprise' work.

    And in future releases, that may be easier and easier to do. Think of
    it this way: Apple decided, for whatever reason, that the existing ObjC
    EOF code was insufficient for their needs (too hard to use, too many
    new idioms to throw at developers all at once, too much dependance on
    the aging EOModeler, whatever). I'd rather they release what they have
    incrementally, so we can use it, than wait years for everything to fall
    into place before it sees the light of day.

    I agree with you and Aaron that the Bindings are missing many things
    that EOF had, and those things should be reintroduced. However, my bone
    of contention is that I don't see them as "basic design flaws" but
    rather as a deliberate simplification. In particular, I believe that
    the simplification is done in such a way that those missing features
    can be introduced at a later point with little difficulty (on the part
    of the end user developer).

    > Seems to me that the NSController layer is to EOF's UI layer as DBKit
    > was to EOF.

    DBKit was before my time. Vague poking around seems to imply that the
    change from DBKit to EOF was driven in large part by the needs of
    WebObjects. (Wild speculation on my part there).

    Karl

    --

    We, the unwilling,
    led by the unknowing,
    have been doing the impossible
    for the ungrateful.
    We've done so much for so long,
    we are now qualified to everything
    with nothing.

    Homepage:
          http://homepage.mac.com/khsu/index.html
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
previous month october 2003 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Go to today