On 12/01/2005 at 13:14, xxxxxxxx wrote:

As much as I like COFFEE, if it's outdated, it doesn't
matter that it's a full-blown language. It is IMO a very
good language, but it's hard to take advantage of it when
the docs and APIs are incomplete.

Is there a reflection API for COFFEE, like there is for
Java? I've seen nothing of the sort, but if it exists, we
could at least compile a reference list of available
objects and methods, which would be a start on docs.

On 10/01/2005 at 15:21, xxxxxxxx wrote:

Never heard of Lua or Ruby, but then I'm not a gaming programmer.

Well, you have to remember that COFFEE isn't a scripting language either. It is a full blown OOPL interface into C4D that can be compiled into a sort of bytecode as well. If we were talking XPresso, that'd be closer to a scripting language. So, I'd have to see the flexibility and robustness of these other two to make a comparison on their efficacy - thanks for the URLs!

Let's put it this way: Maxon has made minor updates to COFFEE since v6.3, but they are neither documented nor, I take it, supported. Maybe we can?

On 10/01/2005 at 13:42, xxxxxxxx wrote:

IMO a Java interface would not be an ok but less than
ideal solution. It is a good language, and I use it quite
a bit for work, but the overhead that goes with it would
be pretty significant, because it wasn't made to be a
lightweight language. The priority has been on other
things, like robustness and expressiveness.

In other words, for a scripting language, it's overkill.

I would prefer something like Lua or Ruby (Ruby ROCKS!),
because they're made to be leightweight scripting languages
and they're also designed with the idea of using them as
high-level interfaces on top of native C/C++ libraries,
which makes them common in the performance-sensitive
gaming industry.

They're also far easier to learn than Java, which is a
huge plus, IMO.

I wouldn't want to inflict the task of building a large-
scale JNI binding on anyone other than the people I got
stuck working for at my previous job, but I'd also not
trust people like that to do it well.

A Lua or Ruby binding I would be interested in helping
with if I can. I hope I have more time for this after I
move toward the end of the month... I'm tired of dealing
with this buying and selling houses stuff.

www.lua.org
www.rubycentral.com

Have Maxon seriously not updated COFFEE since v6.3? Or
is it just that they haven't updated the docs for it?
That's a bit of a bummer. Maybe we can convince them to
pick up Lua or Ruby

On 10/01/2005 at 13:11, xxxxxxxx wrote:

Very interesting, RakeshM. So, have you started yet!? ;0P

Personally, I wish that they'd just ditch COFFEE for a Java interface for cross-platform, built-in coding. It is glaringly obvious that COFFEE cannot be maintained and updated easily (since the last official release is for 6.3). A well constructed Java interface would not require so much restructuring (?).

On 04/01/2005 at 12:25, xxxxxxxx wrote:

There are options like JNI for using native libraries from
Java.

Also, you can get pretty close to native performance (about
as close as Java will get) using JIT compilers; modern
JIT compilers are getting pretty good, with the possible
exception of Sun's.

That way you could get fairly high performance and still
retain platform neutrality -- but it would still be a lot
of work to implement and verify the JNI wrapper.

On 02/01/2005 at 17:17, xxxxxxxx wrote:

Would be an interesting idea (being a Java programmer myself). It would definitely be a lot of work - the C++ interface is massive and the api.lib is about 1MB. The api.lib would need to be ditched for a Java jar or something since it is platform dependent.

Don't forget that Java has built in garbage collection like COFFEE, many available API's, and a full GUI (Swing).

One question is whether to leave it bytecode (which is platform independent but slightly slower running in the VM) or make it native compiled code (which is platform dependent). Of course, as long as a lib target exists for natively compiled Java (to make the plugin), you could allow both.

Robert