Re: .Mac support to C/C++ application
Re: .Mac support to C/C++ application
- Subject: Re: .Mac support to C/C++ application
- From: Rich Wardwell <email@hidden>
- Date: Mon, 24 Apr 2006 02:06:14 -0500
I appreciate your response. I'll check out both of those cocoadev
links...
As far as the late binding, Java does this fairly well, which might
be why Apple did support Java wrappers to Cocoa functionality. Bit
curious to why they dropped it.
On the flip side, I'm still trying to "feel comfortable" with ObjC,
and hope that I do with time. Doesn't necessarily help me with my
day job tasks of developing primarily cross-platform code in C++, but
there your are. My standard modus operandi is a lot of cross-
platform base code in C++ shimming to more platform specific code
(MFC/Win32/WxWidgets/Carbon) on the frontend. This is sometimes
frustrating after using Java for mostly server side development for a
number of years (not that it didn't have it's own problems).
Also, I'm not sure I would compare ObjC to a MagLev train, although I
can go with it... :) While I agree with your analogy in principal,
for a passenger who wishes to travel from Tokyo to London, one must
use a number of different "technologies". The user experience is
best satisfied by a fast, cohesive trip. I think lack of sleep is
making me become a bit obtuse. :)
Rich Wardwell
Software Developer (Java, C++), Mac Fanatic
On Apr 24, 2006, at 1:47 AM, ObjM2 wrote:
Rich Wardwell wrote:
what I believe is a fairly arbitrary and limiting constraint of
Cocoa and its tight coupling with ObjC.
Note that there are quite a number of alternatives to using ObjC
for Cocoa programming:
http://www.cocoadev.com/index.pl?CocoaLanguages
http://www.cocoadev.com/index.pl?CocoaBridges
With the plethora of "Switchers" coming from C/C++/(even Java)
land (including myself), I'm starting to get a little sick and
tired of having the faint feeling that Objective-C is being
rammed down my throat at every turn just to have access to fairly
critical / important APIs that are only found in Cocoa. I really
like Cocoa in principal, but when I'm coding for multiple
platforms in C++, having to shift to ObjC for a single platform is
no fun, and is surely hindering widespread acceptance of Cocoa
development for others in my opinion. This seems somewhat short
sighted and constraining to the future adoption of better or
alternative languages as they appear.
I really think Cocoa & ObjC can / should be separated. One is a
deep, rich and full framework / library, the other an
implementation language. Cocoa can be written in ObjC but still
be fairly agnostic and other language friendly.
Why must they be coupled so tightly together?
The holy grail would be -- whether you want to code in ObjC, Java,
C++, or any other relatively object oriented language that has a
wrapper, Cocoa is available to you. I keep alive the dream that
Apple will provide this utopia someday... :) I know so many folks
who immediately go to Carbon purely because it's C based,
bypassing the much richer and most likely much more appropriate
Cocoa framework / libraries.
To put it in Alan Kay's words ... "It is all about late binding"
and not about -as you put it- "relatively object oriented". In
'Early History of Smalltalk' (http://gagne.homedns.org/~tgagne/
contrib/EarlyHistoryST.html), Kay wrote "OOP an be viewed as a
comprehensive technique for late-binding as many things as
possible". You may also want to read the chapter on "Object-
oriented Style".
Cocoa exploits the power of late binding in ways most other
languages don't and can't and the ones that do often have a serious
performance penalty. The vehicle Cocoa uses to accomplish this,
ObjC, already represents the bringing together those two worlds. It
is fairly unique in that, which may explain why there is no serious
challenger.
Nevertheless, there is nothing that stops you from doing Cocoa
development in any of the many languages which accommodate this. It
will always be the case that knowing the implementation language of
a framework will allow a deeper understanding of the inner workings
of that framework. This is so for any given framework and any given
implementation language.
Also, before anyone notes that learning ObjC isn't that big of a
deal... well, neither is learning C#... or Java... or any other
language -- is this relevant? The fact remains that a language
that is pretty much SOLELY used on one platform (Mac) and is
debatably no better / worse than any of the other object oriented
C-based languages out there, is required to use many of the best
features of the Mac. As new languages arrive, others grow, we are
stuck with a single language as a development platform, with no
other alternatives. Will Objective-C be the best language in ten
years? Frameworks seem to outlast the languages that use them.
Let me give you an analogy ...
Magnetic levitation train systems have been developed in only two
countries (JP and DE) and the technology is deployed only in one
third country (CN) and then only on a single relatively short
railway line (Shanghai City to Shanghai Airport). No screaming and
whining of conventional railway builders along the lines of "The
technology isn't widely used" or "Why can we not just put our
conventional locomotives on those maglev tracks?" will change the
the likely outcome that *eventually* all train systems may well be
maglev. The key here is to adapt to the new paradigm instead of
trying to decapitate the new technology in an attempt to make it
fit the old paradigm. Think of Cocoa is a maglev network and of
ObjC as a maglev engine. They are both based on a new paradigm: No
wheels. Any engine to run on that maglev network has to be a maglev
engine, it can't be a wheel driven one, even as sophisticated as a
Japanese bullet train engine or a French TGV engine.
rgds
ObjM2
___________________________________________________________24 FIFA
World Cup tickets to be won with Yahoo! Mail http://uk.mail.yahoo.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden