> > And C++ doesn't have modules (unless you count namespaces as modules)
>
> C++ and C# have namespaces. I thought a lot about whether they really were modules, as they both missed the boat on what a module was for, but in the end decided they were for the purposes of the comparison. Java has the 'package' concept for modules.

IMO neither packages nor namespaces are modules. To me a module is a runtime component that you can deploy/install and undeploy dynamically. Very few languages support this concept natively (mine does :) Java .jar/.war/.ear files come close, but they're only indirectly supported by the language (in terms of library functions/classes to create and read them). Usually you need some kind of external tool (jar or make) to build modules

> I think delegates are a much better approach than inner classes. And sure, you can emulate them in C++ with a pair, but that gives no type safety.

Both approaches have their use, they are not identical. I thought about this issue some while ago, in terms of function pointers vs. interface implementations. Suppose you have a timer class:

interface TimerEvent {
    void onEvent( Timer& t );
}

class Timer {
    void createTimer( timerCallBack cb, int time );   // some function ptr
type
    void createTimer( TimerEvent& cb, int time );    // interface
}

when the timer fires, you would either do:
a) cb( this )
b) cb.onEvent( this )

The difference is, that the second call passes not only the event but also a context (the instance object implementing 'TimerEvent'). You could achieve the same effect by passing an additional parameter to the function callback, like so: cb( this, context )

In any case, interfaces allow you to specify more than 1 function. So in cases where it makes sense to have a group of related callback functions, an interface is better than a set of otherwise unrelated callback function pointers. But like I said, both can be useful

"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:b3f86t$i3h$1@digitaldaemon.com...
> > > And C++ doesn't have modules (unless you count namespaces as modules)
> > C++ and C# have namespaces. I thought a lot about whether they really
were
> > modules, as they both missed the boat on what a module was for, but in
the
> > end decided they were for the purposes of the comparison. Java has the 'package' concept for modules.
> IMO neither packages nor namespaces are modules. To me a module is a
runtime
> component that you can deploy/install and undeploy dynamically. Very few languages support this concept natively (mine does :) Java .jar/.war/.ear files come close, but they're only indirectly supported by the language
(in
> terms of library functions/classes to create and read them). Usually you
> need some kind of external tool (jar or make) to build modules

That sounds like a DLL.

"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:b3f8o8$icn$1@digitaldaemon.com...
> The difference is, that the second call passes not only the event but also
a
> context (the instance object implementing 'TimerEvent'). You could achieve the same effect by passing an additional parameter to the function
callback,
> like so: cb( this, context )

Essentially two context pointers.

In article <b3eplb$9gd$1@digitaldaemon.com>, Mike Wynn says...
>
>
>"Walter" <walter@digitalmars.com> wrote in message news:b3eild$5kb$1@digitaldaemon.com...
>> I think delegates are a much better approach than inner classes. And sure, you can emulate them in C++ with a pair, but that gives no type safety.
>>
>
>yes and that's exactly why inner classes are great, as I tried to show (with
>some incorrect Java), and why I mentioned delegates.
>in Java anon classes are use to replace delegate, closures and func pointer
>(although that can also be done via the reflections api)
>but that's only one use or anon classes and inner classes.
>
>the java code was crap, an extension to an inner class must be declared
>within an enclosing class than extends its parent.
>which is a pain at times consider:
>
>public class Container{
> public class Item { }
>}
>
>public class Container2 extends Container{
> public class Item2 extends Item { }
>}
>
>public class Test
>{
> public static void main( String[] args )
> {
>  Container c = new Container();
>  Container2 c2 = new Container2();
>  c.new Item();  // valid
>  // c.new Item2();  // invalid  Item2 must be created with an instance of
>Container2
>  c2.new Item();  // valid Container2 isa Container
>  c2.new Item2(); // valid
> }
>}
>
>due to Java's rules its not valid to write
>
>public class MyItem extends Container.Item { ... }
>
>if you want a new type of item you have to have a new container too.
>

If your inner class access something specific to an instance of the outer class you need to write "new Outer().new Inner()", because the 'this' reference must be initialized. But if the inner class doesn't access anything of the outer class, you can make it static, like:

class Outer {
static class Inner {
}
}


And use "new Outer.Inner();".

Sure, D has all these features that C++ and Java don't have (C is not in competition for me, it is a lower level language). But are these features so important ? I have never had big trouble with either C++ or Java. In other words, D is maybe the best, but it is only 10% better than Java and C++. For me, it does not make any difference.

Let's not forget that D comes after C++ and Java...most of the OOP theory is already out there before D. And let's not forget ADA 95: it has all these features and maybe more.

"Walter" <walter@digitalmars.com> wrote in message news:b3csi8$28uo$1@digitaldaemon.com...
> I finally was inspired by Christof's comparison chart, and did one
comparing
> D with various other languages.
>
> www.digitalmars.com/d/comparison.html
>
>

Excellent point!  The "best" language is not always successful: as D shows, there are several ways to improve C++; yet the chances of D overtaking C++ are quite remote.

From my point of view; D would be a lot more popular if it integrated with .NET and Visual Studio .NET.  Look how fast C# has taken off; and a lot of "legacy" languages are getting a new lease on life by being "ported" to the CLR.  Microsoft's extensions to C++ (Managed C++) show that you can (almost) have your cake and eat it too: compile to object code for performance, or to MSIL for .NET.

   Dan

"Achilleas Margaritis" <axilmar@in.gr> wrote in message news:b3fhat$miu$1@digitaldaemon.com...
> Sure, D has all these features that C++ and Java don't have (C is not in competition for me, it is a lower level language). But are these features
so
> important ? I have never had big trouble with either C++ or Java. In other words, D is maybe the best, but it is only 10% better than Java and C++.
For
> me, it does not make any difference.
>
> Let's not forget that D comes after C++ and Java...most of the OOP theory
is
> already out there before D. And let's not forget ADA 95: it has all these features and maybe more.
>
> "Walter" <walter@digitalmars.com> wrote in message news:b3csi8$28uo$1@digitaldaemon.com...
> > I finally was inspired by Christof's comparison chart, and did one
> comparing
> > D with various other languages.
> >
> > www.digitalmars.com/d/comparison.html
> >
> >
>
>

"Achilleas Margaritis" <axilmar@in.gr> wrote in message news:b3fhat$miu$1@digitaldaemon.com...
> Sure, D has all these features that C++ and Java don't have (C is not in competition for me, it is a lower level language). But are these features
so
> important ? I have never had big trouble with either C++ or Java. In other words, D is maybe the best, but it is only 10% better than Java and C++.
For
> me, it does not make any difference.

Improving your productivity by 10% is actually quite a big deal. That's over an extra month a year. If you make $100,000 a year, that's an extra $10,000 in your pocket.

> Let's not forget that D comes after C++ and Java...most of the OOP theory
is
> already out there before D. And let's not forget ADA 95: it has all these features and maybe more.

You're right about OOP theory. D doesn't add much there, where D adds is in things that go beyond OOP like design by contract, closures, etc.

"Walter" <walter@digitalmars.com> wrote in message news:b3fdlp$kp1$2@digitaldaemon.com...
>
> "Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:b3f86t$i3h$1@digitaldaemon.com...
> > > > And C++ doesn't have modules (unless you count namespaces as
modules)
> > > C++ and C# have namespaces. I thought a lot about whether they really
> were
> > > modules, as they both missed the boat on what a module was for, but in
> the
> > > end decided they were for the purposes of the comparison. Java has the 'package' concept for modules.
> > IMO neither packages nor namespaces are modules. To me a module is a
> runtime
> > component that you can deploy/install and undeploy dynamically. Very few languages support this concept natively (mine does :) Java
.jar/.war/.ear
> > files come close, but they're only indirectly supported by the language
> (in
> > terms of library functions/classes to create and read them). Usually you
> > need some kind of external tool (jar or make) to build modules
>
> That sounds like a DLL.
>
Yes, you can consider a DLL as a module. However, the decision of which classes to put in the DLL is not made by the C++ compiler, but usually by some makefile. I develop more in Java and regularly find myself defining classes, packages, and a separate deployment descriptor for my .wars and .ears. Yes I know there are tools for that too, but my point is that it's not built into the compiler. It could be

"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:b3gtjc$1iqr$1@digitaldaemon.com...
> > That sounds like a DLL.
> Yes, you can consider a DLL as a module. However, the decision of which classes to put in the DLL is not made by the C++ compiler, but usually by some makefile. I develop more in Java and regularly find myself defining classes, packages, and a separate deployment descriptor for my .wars and .ears. Yes I know there are tools for that too, but my point is that it's not built into the compiler. It could be

The 'export' attribute in D is used to control what is visible outside of a DLL. I know that's not what you're driving at, but it is a step in that direction.