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: Allan Odgaard <email@hidden>
- Date: Thu, 10 Jun 2004 08:54:25 +0200
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 ;)
_______________________________________________
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.