Re: Cocoa newbie frustration
Re: Cocoa newbie frustration
- Subject: Re: Cocoa newbie frustration
- From: "Erik M. Buck" <email@hidden>
- Date: Mon, 8 Oct 2001 13:45:03 -0500
>
On a scale of 1-10, I'm about a 3 at C++, Java, and Object-Oriented
>
Design. After two or three days of reading
Given your self assesment, my guess is that you don't yet know what is wrong
with C++ when it is applied to certain applications.
>
/Developer/Documentation/Cocoa/ObjectiveC, I'm a little dismayed by what
>
strikes me as ObjC's primitiveness and awkwardness in comparison to C++
>
and Java. [Yes, I know, claiming that C++ is not awkward is highly
>
debatable, but by adhering to good usage rules, such as those in Scott
>
Meyers' Effective C++ series, it can be brought more under control].
Objective-C is not awkward. IMHO it is very elegant. However, if
Objective-C does not fit your way of thinking then it may not be for you.
>
>
My main question is: can anyone point to a well-written, even-handed
>
compare/contrast of ObjC versus C++ and/or Java? I would especially be
>
interested in learning about the pluses and minuses of dynamic binding,
>
since it seems to me to allow imprecise thinking (not to mention a
>
runtime penalty), and might be avoidable with a more disciplined
>
approach to software design. Then again, maybe there's a less anal
>
philosophical approach to software engineering that I need to explore!
>
>
My other question is: is it likely, or even possible, that there will
>
eventually be a C++ alternative to the Cocoa/ObjC programming
>
environment for OS X?
There is a C++ alternative: MacApp for Carbon. There is also the Metroworks
C++ class libraries for Mac.
You are not likely to ever see C++ bindings for Cocoa because C++ is just
not dynamic enough. That is why COM, SOM, DCOM, IDL, CORBA, manual messages
maps, and countless other extra-language elements have been created for C++.
None are needed in Objective-C.
See:
http://www.amazon.com/exec/obidos/ISBN=0201548348/104-4392555-3761532
See:
http://www.toodarkpark.org/computers/objc/introobj.html#721 from which
I exracted the following text without permission:
Why Objective-C
The Objective-C language was chosen for the OPENSTEP development environment
for a variety of reasons. First and foremost, it's an object-oriented
language. The kind of functionality that's packaged in the OPENSTEP software
frameworks can only be delivered through object-oriented techniques. This
manual will explain how the frameworks work and why this is the case.
Second, because Objective-C is an extension of standard ANSI C, existing C
programs can be adapted to use the software frameworks without losing any of
the work that went into their original development. Since Objective-C
incorporates C, you get all the benefits of C when working within
Objective-C. You can choose when to do something in an object-oriented way
(define a new class, for example) and when to stick to procedural
programming techniques (define a structure and some functions instead of a
class).
Moreover, Objective-C is a simple language. Its syntax is small,
unambiguous, and easy to learn. Object-oriented programming, with its
self-conscious terminology and emphasis on abstract design, often presents a
steep learning curve to new recruits. A well-organized language like
Objective-C can make becoming a proficient object-oriented programmer that
much less difficult. The size of this manual is a testament to the
simplicity of Objective-C. It's not a big book--and Objective-C is fully
documented in just two of its chapters.
Objective-C is the most dynamic of the object-oriented languages based on C.
The compiler throws very little away, so a great deal of information is
preserved for use at run time. Decisions that otherwise might be made at
compile time can be postponed until the program is running. This gives
Objective-C programs unusual flexibility and power. For example,
Objective-C's dynamism yields two big benefits that are hard to get with
other nominally object-oriented languages:
Objective-C supports an open style of dynamic binding, a style than can
accommodate a simple architecture for interactive user interfaces. Messages
are not necessarily constrained by either the class of the receiver or the
method selector, so a software framework can allow for user choices at run
time and permit developers freedom of expression in their design.
(Terminology like ``dynamic binding,'' ``message,'' ``class,'' ``receiver,''
and ``selector'' will be explained in due course in this manual.)
Objective-C's dynamism enables the construction of sophisticated development
tools. An interface to the run-time system provides access to information
about running applications, so it's possible to develop tools that monitor,
intervene, and reveal the underlying structure and activity of Objective-C
applications. Interface Builder could not have been developed with a less
dynamic language.
See
http://groups.google.com/groups?q=Erik+Buck+closed+universe+Objective-C+grou
p:comp.sys.next.*&hl=en&rnum=1&selm=844ijs$jol$email@hidden
.net
Reasons for run-time "LATE" binding:
Plug in classes
Beans
Use of shared frameworks that change without recompiling applications
Simple/Natural Distributed Objects without IDL
Language bridges (Java -> Objective-C) (Perl/TCL/Python -> Objective-C) etc.
Reduction in complexity of common design patterns
Elimination of need for some common design patterns
Reasons to avoid run-time "LATE" binding in favor of compile/link time
binding:
You have a "closed universe" problem and every detail is known in advance so
flexibility is not needed
Verification - It is sometimes necessary to PROVE that a solution is correct
in all cases and this is complicated by Java or Objective-C runtimes