Re: newbie questions about objective-c, ruby, python, groovy and cocoa
Re: newbie questions about objective-c, ruby, python, groovy and cocoa
- Subject: Re: newbie questions about objective-c, ruby, python, groovy and cocoa
- From: "KlunkyRobot" <email@hidden>
- Date: Thu, 10 Jun 2004 01:06:54 -0700
Thank you for your input. Your information on method overloading and
namespaces are good, as well as why c++ defeated objective-c in race for
leadership?
However just to be the devil's advocate, Java came to the world after C++
and Objective-C and Java has now almost eclipsed C++, and now C# has come
unto the scene and it looks like it will eclipse all others. So turning
up late cannot be that of a negating factor in a languages success.
But I do take your second point about C++ not having the overhead.
In regards to method overloading I can create two files called
MyMethods.m and put one in a folder like this /utilities/MyMethods.m and
/maths/MyMethods.m is that correct or will they conflict if I call them
into the same file header.
To be honest Objective-C syntax is ugly from a Java syntax point of view,
I hope that it is just a lack of familiarity on my part.
I however also believe that Apple never intended or wished to have any of
these other frameworks on Mac OSX. Carbon was just for those stalwarts
that refused to port their apps to cocoa like Adobe and MS. Java was only
supported because it is universally popular amongst developers but it has
really bean neglected by Apple. If Apple gave Java primary support as
Java deserved I would not be even bothering to look at objective-c and
cocoa. Cocoa is Apples primary choice everything else is an afterthought.
Regrettable but true.
Kurt
==================
==================
On 10/06/2004, at 4:54 PM, Allan Odgaard wrote:
On 10. Jun 2004, at 6:11, KlunkyRobot wrote:
After looking around it is my opinion that Cocoa applications are the
only true First Class Citizens on Mac OS X. Do you agree or Disagree?
Definitely agree. Carbon applications can probably come very very close,
but because so much has to be done manually, very few (if any) succeeds
in going the full way.
Although some stuff is simply not possible with Carbon, like the
customizable key binding system.
1- Objective-c does not seem to support package namespaces why is this
so? It seems that you can use groups in XCode to group files but this is
only visual it still leaves all files lying in one folder, which I could
see becoming a management nightmare.
You can make real directories for your files, but you won't get
namespaces (or packages for that sake). The convention is to prefix your
class names with the namespace. I haven't really thought it through, but
the lack of namespaces probably has to do with the run-time, it would
need to be given a prioritized list of namespaces to search when looking
up a class, and the call-place would need to have such a list -- it's
probably to complicated for the little it adds (since all classes are
already prefixed).
2- Method Overloading - Is it true that this is not supported in
Objective-c [...]?
It supports it only when the number of arguments differ. The reason is
probably twofold, 1) there is no type-info given in a selector (the type
of a 'method', which is independent of the class) and 2) objective-c is
supposed to be a dynamic language, so calling the method with a string or
a number makes no difference, they are both objects...
3- Is it true that you can combine the header interface definition in the
same file as the implementation? [...]
You can, but if other files needs to use the class, they will need to see
(i.e. #import) the interface (but not the implementation), so for public
classes it's not practical to do so.
4- What version is Objective-C at, is their a standard ISO Objective-C
that is under review and development or is this just Apples show? [...]
This is an Apple show -- they do evolve the language slightly, but since
it is an extension of C99 or C++98, it piggy-backs on the these.
5- [...] what drove developers and companies to choose C++ over
Objective-C?
I'm not very old, so you'll have to forgive me if my history is wrong.
But AFAIK C++ is from '82 and ObjectiveC is from '86, and that is really
*much* later in computer-years ;)
Furthermore, C++ has zero (run-time) overhead, which makes it good for
writing device drivers, operating systems, compilers or other things
where speed is important -- another advantages is the lightweight syntax
when introducing own types, which makes it very good for "scientific
programming", e.g. image manipulation programs, compression/encryption
software a.s.o.
Neither of the above is IMHO true about ObjectiveC.
And dose this say anything about Objective-C?
A fundamental difference between C++ and ObjectiveC is that the former is
statically typed, and the latter is dynamically typed.
Having ObjectiveC dynamically typed is a huge advantage when exchanging
"data" (objects) between applications, for this C++ is unusable and on
Windows they have COM to solve that problem.
It also has other advantages not found in C++, like reflection, open
classes, catching unimplemented methods a.s.o. which allow for a
programmer to "code by convention" and then have the run-time do a lot of
magic using the previously mentioned technologies. This is a huge
advantage in OO frameworks like the Application kit or a Object Relation
Mapper-frameworks like the Web Objects / Enterprise Objects (although I
have not looked closer on this framework).
[...] how hard would such a bridge be to develop?
I think it mostly depends on the Groovy implementation. There is only a
minimal number of functions to talk to the objective-c run-time, this
includes registering a class, a method of the class and obtaining info
about classes in memory.
I guess a bridge would hook into class creation in the language and
register a counterpart with the run-time which calls into Groovy (so that
the Cocoa framework can call back to Groovy classes) and similar would
create Groovy counterparts for the Cocoa classes (on demand) which would
call out to the Objective-C run-time when used inside Groovy.
Given that both ObjC and Groovy are dynamically typed, I'd imagine that
it should be pretty straightforward, but w/o having studied the Groovy
implementation, my words should be taken with a grain of salt ;)
Ruby and Python
[...] is any one on this list using these languages with Cocoa
No idea...
2 -Does anyone think that it is best to simple stick with objective-c
with cocoa as this will have the largest relative development community
in regards to Cocoa?
For the general programmer I'd say stick with Objective-C, you are
certain that this is always up to date, the documentation examples use
this langauge, many can help you with potential problems and you can
interface whatever other library you may need due to how it is just an
extension of C/C++.
That said, if you are in it for the fun of it, if you don't mind perhaps
contributing to the bridging if it turns out to be incomplete, and/or you
don't mind waiting a little while to play with the latest additions to
Cocoa released together with Tiger (does automatic change notifications
work for the Java bridge? and will it ever?), then I'd say go for
RubyCocoa, this is certainly a much more fun language than ObjectiveC,
and it has much more power...
There are only two things holding me away from RubyCocoa, one being that
I'm an algorithm-guy, and here C++ just appeals so much more to me, the
second thing is that I think it looks ugly when the methods are rewritten
with underscores instead of spread out with colon preceding the
interleaved arguments (but perhaps that can be enhanced with Ruby's named
arguments).
When I complete my current project I'll try to find a project light on
algorithms and write it with RubyCocoa ;)
--
http://www.fastmail.fm - The way an email service should be
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.