Re: [GD-General] The D Programming Language

[Brian H. <bri...@py...>]

At 01:32 AM 12/27/2001 -0500, Patrick M Doane wrote:
>On Mon, 24 Dec 2001, Brian Hook wrote:
> > At 10:44 PM 12/24/2001 -0800, Grills, Jeff wrote:
> > >It seems to retain the things I use most in C++, strips away a lot of
> > >cruft I don't care for, and adds a lot of things I really wish C++ had.
> >
> > This actually describes Java (for me).  I'm still torn between Java and
> > Obj-C.  The sheer power from a dynamically typed system is something I'd
> > hate to eschew, which is why Obj-C keeps lingering in the background.
>
>Are you claiming that Jeff's description of why he likes D is why you like
>Java or that the D language looks a lot like Java to you?

The former (i.e. what he likes about D is what I like about Java).

>I'm particularly interested in the struggle between static / dynamic type
>systems.  Why do you feel that dynamic typing is so much more powerful?
>Could you provide some concrete examples?

Maybe "powerful" is the wrong term, but "convenient" trivializes it too 
much, so somewhere in between.

Case in point: Obj-C has the notion of an "informal protocol".  All that 
means is that you can ask that some object responds to some message.

id foo = [[Foo alloc] init ];

[foo ThisIsSomeRandomMessage]; //This will ALWAYS compile

When the above is run, if the class "Foo" doesn't understand that message, 
it will generate a run-time exception.

Small aside -- if you had put "Foo *foo" instead of "id foo", it would have 
generated a warning that "Foo does not understand ThisIsSomeRandomMessage", 
so you get the benefits of both static type checking and dynamic typing 
depending on your mood.  The rule is to "specify type when you know it".

A more concrete example is delegation.  You can assign a delegate to an 
object, and the delegate is responsible for handling some random task.  In 
C you would do this with a callback and some parameters:

void (*delegatefunc)(void*parms);

p->registerDelegateFunc( delegatefunc );

You'd then do a bunch of casting and what not in your delegatefunc to get 
it to work.  In C++, you'd also have to make sure it was friends or had 
appropriate permissions, etc.

In C++, you would probably use MI, which is overkill IMO:

class Foo : public SomeDelegateClass. DelegateClass2, yadda yadda
...

Foo *f = new Foo;
p->registerDelegate( f );

This gets real cumbersome when you have a centralized object, like your 
application, as a delegate for a dozen other objects.

In Obj-C, common places for delegates include "shouldWindowClose" and 
things like that.  Before closing, the window will ask its delegate if it's 
okay to close, etc.  Cocoa, in fact, deprecates inheritance in favor of 
delegation.  Read the Cocoa docs when you get a chance (there are some 
basic introduction to Cocoa and Obj-C docs at the Apple site).

Another place this is nice is that you can get handy container classes that 
can be of any type without forcing gargantuan recompiles and difficult to 
read warnings/error messages.  Aside from technical issues, I think 
templates are difficult to decipher, debug and just plain use in common day 
to day practices.

Dynamically typed container classes are more convenient for me because 
you're not recompiling EVERYTHING just because you've changed how a 
container class works (or how you've instantiated one).  Since classes are 
first class objects (no pun intended), you can pass the class of an 
incoming object as a parameter to make a container of "things like that 
object".

These are pretty trite but common examples.  Post to comp.lang.objective-c 
for some better ones =)

> > But Java's GC and "portability" are also very tempting.
>
>I've heard a colleague describe Java as "write once, debug everywhere".

Early incarnations of Java definitely suffered from this, and I'm sure they 
still do.  Java is evolving rapidly, and while the JREs seem to be 
relatively stable, the libraries are constantly being upgraded, improved, 
fixed, etc.  The AWT->Swing transition and the original container classes 
-> Java collections were pretty major shifts.

So yeah, it's not perfect, which is why I put "portability" in quotes, 
however it's definitely better than trying to find a compiler and 
associated libs for each platform (such as with Eiffel).

>improvements in this area?  Is it a feasible language for developing
>serious games or is it better suited to in-house tools?

Well, there are "not serious" games written in Java (and Flash/Shockwave) 
all over the Web (www.popcap.com or www.gamehouse.com for examples), so it 
can definitely be done.  There are MUD servers written in Java also, and 
there was that Java version of Quake or Doom (JDoom?) that came out a while 
ago.  I plan on using Java for my own server technology, at least enough 
such that I can figure out if it's appropriate or not.

At a high level, I think Java should work fine for games of almost any 
type.  The few places that need to be optimized or that need to get to low 
level system resources (e.g. AGP allocated memory) can be handled through 
JNI, but in the end for a hardcore technology oriented game, the Java 
component would actually turn out to be very small.  For a game where the 
design took precedence over the technology (i.e. the technology was more of 
an implementation detail instead of a selling point) then I think Java 
should work fine.

Brian