On Aug 22, 2005, at 11:45 AM, John Pfersich wrote:
I didn't quite read the whole announcement, but are you going to
use the Object C library runtime?
Yes.
Apple's runtime on MacOS X, the GNUstep runtime elsewhere.
It says in the announcement that
" While we need to stay compatible with the ObjC runtime... ", but
does that mean that you'll have another, separate runtime?
No it means that we can add or change things only within the limits
set by the ObjC runtime.
As an aside, I find this all quite amusing because I'm, by preference,
a Smalltalker, and I'm always snickering when I see "Smalltalk based"
or "Smalltalk-like".
Although we do find ObjC's bracketed message passing syntax rather
suitable because it is more expressive than simple function calls,
you are nevertheless mistaken when you label ObjC or ObjM2 to be
"Smalltalk like" or "Smalltalk based". Just because the message
passing syntax is Smalltalk based doesn't mean the entire language
is. The attraction to use the ObjC approach is precisely because it
is such a powerful blend of both worlds.
Also, you seem to be under the impression that the purpose of our
project is to create a new language for the sake of creating a new
language. But that's not the case at all.
The purpose of our project is to provide an interface to Cocoa and
GNUstep for Modula-2. In other words, we are creating a kind of
foreign function interface for Modula-2. That is all there is to it.
In an all procedural, all statically typed world, such an exercise
would be almost trivial and the only syntax you'd have to add would
be something like a FOREIGN keyword or compiler directive. The result
wouldn't be considered a hybrid language nor a new language, either.
Yet, interfacing to Cocoa and GNUstep is a little more complicated
due to a) the dynamic typing and binding of the ObjC runtime
environment and b) the Smalltalk message passing syntax.
Anybody else who created an interface to Cocoa/GNUstep for other
languages has chosen to develop an ObjC bridge. This allows
integration in a manner that looks fairly seamless from a syntax
point of view, but the interface itself is anything other than seamless.
Just take a look at the sources of the PyObjC project, the Python/
ObjC bridge. You'll see that there are many problem cases and
unsupported cases where the bridge is unable to interface to certain
Cocoa methods. And with every new version of OSX, Apple introduces
more Cocoa APIs and retires older ones, so you are shooting at a
moving target. You can avoid all those issues by adopting the ObjC
approach as it is far easier and more efficient to teach an existing
compiler to understand the bracketed message syntax than to write and
maintain a bridge.
There's a Smalltalk for the Mac being developed over at
www.ambrai.com,
it has both Carbon and Cocoa "bindings".
We are using Squeak for experimentation to see if there is anything
else in Smalltalk that should have an impact on the design of ObjM2.
While this is interesting and inspiring, nobody has so far decided to
go all-Smalltalk, lock, stock and barrel. Just because we like some
aspects of Smalltalk and decide to incorporate them, doesn't mean we
aspire to an all-Smalltalk environment.
Do I like [object doSomething] and [object doSomethingWith:something] ?
Yes, very much so!
Do I like [object hasProperty] ?
Yes, very much so!
But do I like [object > something ifTrue: doSomething] ?
Absolutely not!
I very much prefer ...
IF [object hasProperty] THEN
(* statement/s *)
ELSIF ...
(* statement/s *)
ELSE
(* statement/s *)
END;
which BTW is one of the attractions of ObjM2 over ObjC, because M2's
IF-THEN-ELSIF-ELSE-END is clean and structured no matter how many
nesting levels you have while C's if-else can very easily get out of
hand with its curly braces, the dangling else issue etc.
And there are many other things beyond syntax which most developers
will never like about Smalltalk. Efficiency in particular. Does it
always have to be dynamic typing? We prefer it the ObjC way, where
you have a choice between statically and dynamically typed objects.
Likewise for garbage collection. There is little doubt that
eventually there will be automatic garbage collection for ObjC (and
ObjM2). But it is likely to be by choice again, so you can choose if
you want an object to be garbage collected (TRACED in M2 terminology)
or not (UNTRACED in M2 terminology). ISO Modula-2's OO extension
already provides this choice.
But please don't be offended by these remarks. They don't mean to say
that Smalltalk is not an amazing environment. It is! But it is all
about choice. You should consider yourself happy that you have have
your preferred environment, Smalltalk, with Cocoa support as a choice
on the Mac.
Modula-2 and Pascal programmers don't have this choice. They have to
make a decision between using Carbon only or move to another language
family they may not like. For some this is like a choice between a
rock and a hard place. ObjM2 is supposed to fill in this missing choice.
Sorry for the OT aside.
Not at all. The question "Why do you do this anyway?" should always
be legitimate and it deserves a serious answer.
rgds
ObjM2 project
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/objc-language/email@hidden
