On 5/27/06, Yen-Ju Chen <[EMAIL PROTECTED]> wrote:
So there are two different reasons to have bindings to GNUstep.
One is to offer a scripting language to interact with GNUstep.
Therefore, it can be treated as a script version of Objective-C.
The language itself can be very small since GNUstep already
offers most of the functions/classes.
The other one is that the language itself has a lot of functions already,
like Perl or Ruby.
The binding merely offers a GUI for these scripting languages.
In other word, most of the Foundation will not be used in this kind of binding
because the scripting has something equivalent already.
So Io language belongs to the first one, and Haskell belongs to second one.
Well, I think the first one is the one we need more.
Well, I can see different scenarios involving mixed languages; on one
hand, we can consider when the language would be useful for us:
- "easier" languages than objc (ruby, smalltalk..)
-> can be used for scripting
-> for developing if fast enough (think Python with Gtk, a couple
quite popular)
- languages that bring additional value to gnustep/étoilé
-> by their characteristics (haskell, erlang.. ada, eiffel?)
-> by giving access to code we can reuse (C++, java)
and on the other hand, you can have languages that could be considered
as less interesting (at least for us), but which could themselves be
interested by gnustep, eg to take advantage of the gui classes, of
gorm, etc.
Then of course you can have different use (eg using foundation or not,
etc) as you highlighted...
Well anyway... There's two general approaches I think for bindings:
- either they interact directly with the objc runtime, as io does, and
can access transparently objects in either way
- or they aren't, eg StepTalk
StepTalk only executes chunks of code, it's not a language bridge,
it's an architecture for easily enabling scripting into applications
(expose objects to the scripts, etc) and integrating under a common
umbrella any "script language" as long as it provides a way for
executing StepTalk "methods". Which means the "script language" only
need to provide a way to execute a script -- it's no bridge... afaik,
STActor "simulates" an object, so you _can_ have an "object" written
using any of the available language, but obviously it's quite a
performance hit compared to having a real bridge.
What would be neat would be to add to steptalk the capacity of taking
advantage of a bridge for a language if there is one. Unless I'm wrong
(could be, because I didn't check the last development with
steptalk...) it's not possible currently.
--
Nicolas Roard
"I love deadlines. I like the whooshing sound they make as they fly
by." -- Douglas Adams
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
