Re: Visualizing Cocoa
Re: Visualizing Cocoa
- Subject: Re: Visualizing Cocoa
- From: jgo <email@hidden>
- Date: Mon, 18 Jun 2001 01:57:14 -0700
>
First off, Jeff, what's UML??
Unified Modeling Language
It's been developed by the "3 amigos": Grady Booch (_OO Analysis &
Design_), James Rumbaugh (_Object Modeling Technique_) & Ivar Jacobson
(_OO Software Engineering_). Look in on the alt.software-eng usenet
group (they've had some good discussions of the relative merits of
Eiffel, SmallTalk, etc.), and/or take a look at these and a whole
slew of newer UML books.
>
...Inheritance is cool, but it gets in the way...
Restrictions on it can get in the way, I suppose.
>
It's easy to let extra dimensions of complexity confuse the issues,
>
but when it all comes down to it all programs simplify into
>
processor commands in serial procession. All any programmer
>
ever does is twiddle bits, or push them from one place to
>
another. Any "style" of programming is only an abstraction.
It's all 1s and 0s; how complicated could that be? :B-)
I wish I had a $ for every student I've told that
one to get them over beginner's trepidation.
>
When dealing with a new framework, or paradigm, it does take
>
a little more effort. In Cocoa, for example, there seems to
>
be some Cocoa mojo going on since things seem to magically
>
happen
or not happen
>
. I guess that's part of the downside for people new to
>
Cocoa/OOP -- that Cocoa "offers so many things for free".
Yes, that is the great promise, only partially fulfilled.
Several examples of perversity have come to light on the
lists recently. Instead of toggling the visibility of
certain visual objects, one is expected to "remove" them
and "add" them. Instead of the size of the parent window
limiting the size of a drawer, it "determines" it, contrary
to the normal behavior of views. Though you can find out
the parent window once you have the drawer, you cannot get
to the parent window from the clicked button in a drawer
because you cannot get to the drawer from that button.
The auto-size adjustment of a view (within a view or window)
tends to drift such that, e.g. in the multi-column sample
code, repeatedly resizing the window can cause the positions
of the columns (views) within it to have them step all over
each other and even to drift out of view.
Another class of odd behavior has to do with setting up
handlers of various kinds which seem to be called at
times unexpected from reading the docs, and not to be
called at expected times (not exactly the same set of
things referred to, above).
Some things are named in weird ways contrary to their
nature (though I'm so tired just now I don't have any
examples fresh at hand, but awakeFromNib is close).
>
But even though there are mysteries, every program must
>
obey the same basic laws of computer processors -- namely
>
"one operation at a time, please" (even threads).
Not if you're running on a Cyber 7600 (to give an ancient
example) or a Connection Machine (to give a not-so ancient
one) or even a 2-headed G4, in which you have multiple
processing units.
John G. Otto Nisus Software, Engineering
www.infoclick.com www.mathhelp.com www.nisus.com software4usa.com
EasyAlarms PowerSleuth NisusEMail NisusWriter MailKeeper QUED/M
My opinions are probably not those of Nisus Software, Inc.