www.digitalmars.com         C & C++   DMDScript  

D - D vs. Java

reply Knaar <Knaar_member pathlink.com> writes:
This be my first post. First of all, I have to rant and rave about how much I
like D. I read someone posted that there's "no original concepts" in D but that
to me is totally irrelevant. Experiemental languages with blow-your-mind
concepts are rarely practical to use. I like D's amalgamation of useful and
practical features from a veriety of languages.

The first thing I would like to critisize, however, is D's approach to objects.
The thing I was most disappointed about was the lack of classes/objects being
utilised in the std.* modules. In Java everything *MUST* be an object. There is
no such thing as stand-alone functions or methods, all functions are members of
classes which in turn can be instantiated into objects. This "everything is an
object" approach is an ideal, I know, but it does have a lot of up-sides to it.
Any Java, Smalltalk, Ruby, C#, etc programmer is usually absolutely obsessed
with objects and would find the std.* library extremely inadiquate, if not
flatly unusable.

Now, I know there really isn't a huge need for a String class, but I would still
like the option of using one. The main reason being that char[] is mutable,
while usually a implementation of String is immutable. This allows for a great
deal of optimizations on strings, allowing duplicates to be eliminated easily.
Vectors and Hashtables are totally unwarented though. A nice linked list
implementation would be useful, though. Perhaps some generic templatized sorting
algorithmns.

Also, I'm not sure if you can do this (I don't think you can) but the ability to
have a class contain C methods. For example:

class FileMethods {
extern (Windows):
public:
HANDLE CreateFileA(...);
HANDLE CreateFileW(...);
}

That way, those of us bent on never having any stand-alone methods can wrap
these methods in classes. This prevents the need to write wrapper methods that
just call the C method.
Feb 17 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Knaar" <Knaar_member pathlink.com> wrote in message
news:c0u870$29fj$1 digitaldaemon.com...
 This be my first post. First of all, I have to rant and rave about how

 like D. I read someone posted that there's "no original concepts" in D but

 to me is totally irrelevant. Experiemental languages with blow-your-mind
 concepts are rarely practical to use. I like D's amalgamation of useful

 practical features from a veriety of languages.

 The first thing I would like to critisize, however, is D's approach to

 The thing I was most disappointed about was the lack of classes/objects

 utilised in the std.* modules. In Java everything *MUST* be an object.

 no such thing as stand-alone functions or methods, all functions are

 classes which in turn can be instantiated into objects. This "everything

 object" approach is an ideal, I know, but it does have a lot of up-sides

What is ideal about everything being an object? Can you offer some proof to back up your statement?
Feb 17 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
Matthew wrote:
 What is ideal about everything being an object? Can you offer some proof to
 back up your statement?

It is in fact very useful to be able to handle everything that can carry data as an object, since it allows to dispatch by type at run-time. However, the correct solution to that is automatic boxing, which would be a perfect addition to D's multiparadigm type system. -eye
Feb 18 2004
prev sibling next sibling parent Ant <Ant_member pathlink.com> writes:
In article <c0u870$29fj$1 digitaldaemon.com>, Knaar says...
This be my first post. First of all, I have to rant and rave about how much I
like D. I read someone posted that there's "no original concepts" in D but that
to me is totally irrelevant. Experiemental languages with blow-your-mind
concepts are rarely practical to use. I like D's amalgamation of useful and
practical features from a veriety of languages.

The first thing I would like to critisize, however, is D's approach to objects.
The thing I was most disappointed about was the lack of classes/objects being
utilised in the std.* modules.

D is proud of being multiparadigma. I believe soon a full OO library will have to be created.
In Java everything *MUST* be an object. There is
no such thing as stand-alone functions or methods, all functions are members of
classes which in turn can be instantiated into objects. This "everything is an
object" approach is an ideal, I know, but it does have a lot of up-sides to it.
Any Java, Smalltalk, Ruby, C#, etc programmer is usually absolutely obsessed
with objects and would find the std.* library extremely inadiquate, if not
flatly unusable.

Every thing is an object. Every program uses objects. Every programer programs with objects. Same don't know it. poor guys.
Now, I know there really isn't a huge need for a String class, but I would still
like the option of using one.

Vathix created one. I'm always about to included in my project. I just browsed it and seems really usable (at the very least is a good staring point) but I never really used it.
The main reason being that char[] is mutable,
while usually a implementation of String is immutable. This allows for a great
deal of optimizations on strings, allowing duplicates to be eliminated easily.
Vectors and Hashtables are totally unwarented though. A nice linked list
implementation would be useful, though. Perhaps some generic templatized sorting
algorithmns.

Also, I'm not sure if you can do this (I don't think you can) but the ability to
have a class contain C methods. For example:

class FileMethods {
extern (Windows):
public:
HANDLE CreateFileA(...);
HANDLE CreateFileW(...);
}

That way, those of us bent on never having any stand-alone methods can wrap
these methods in classes. This prevents the need to write wrapper methods that
just call the C method.

Ant
Feb 17 2004
prev sibling next sibling parent reply Juanjo =?ISO-8859-15?Q?=C1lvarez?= <juanjux NOSPAMyahoo.es> writes:
Knaar wrote:

 
 The first thing I would like to critisize, however, is D's approach to
 objects. The thing I was most disappointed about was the lack of
 classes/objects being utilised in the std.* modules. 

I don't have any problem with functions, they are useful and make sense sometimes where methods doesn't (public static void main LOL...). For example, I'm writing a port of almost all the Linux/Unix libc-API to D, mostly functions. Part of that API will be later wrapped in objects (terminal, socket-stream, process, pipe-stream, mmap-stream, etc) but part won't, because it has little sense to create an object just to make a directory (mkdir), to change the uid (setuid), or to put an environment var (putenv) (and it would be pretty absurd to encapsulate fork() in an object, given his nature). Objects are nice and I use them all the time, but sometimes structs and functions just fits better.
 In Java everything 
 *MUST* be an object. 

I prefer choice.
 There is no such thing as stand-alone functions or 
 methods, all functions are members of classes which in turn can be
 instantiated into objects. 

Well, then tell me what's exactly the different between a class only containing static methods (and java have some of those) and a module just containing functions?
 This "everything is an object" approach is an 
 ideal.

Not for me.
 I know, but it does have a lot of up-sides to it. Any Java, 
 Smalltalk, Ruby, C#, etc programmer is usually absolutely obsessed with
 objects and would find the std.* library extremely inadiquate, if not
 flatly unusable.

std.* is very young, I'm pretty sure that with some time we all are going to have a nice class library, but calling a library "flatly unusable" because it is not 100% object oriented is very short-sighted, IMHO.
 Now, I know there really isn't a huge need for a String class, but I would
 still like the option of using one. The main reason being that char[] is
 mutable, while usually a implementation of String is immutable. This
 allows for a great deal of optimizations on strings, allowing duplicates
 to be eliminated easily.

I also would love to have a nice string object with tons of useful methods (my absolute favourite one is Szymon Stefanek's KVIrc irc client string class).
 Vectors and Hashtables are totally unwarented 
 though. 

Since D supports templates I'm pretty sure a nice container library will be a part of std shortly, there is already people working on it on this forum.
 Also, I'm not sure if you can do this (I don't think you can) but the
 ability to have a class contain C methods. For example:
 
 class FileMethods {
 extern (Windows):
 public:
 HANDLE CreateFileA(...);
 HANDLE CreateFileW(...);
 }
 
 That way, those of us bent on never having any stand-alone methods can
 wrap these methods in classes. This prevents the need to write wrapper
 methods that just call the C method.

Sorry if I sound to harsh but that would be stuuuuuuuuuuupid. What is, again, the advantage of that compared to having those functions in a module FileFunctions if wrapping them in a file class doesn't make sense?
Feb 17 2004
next sibling parent reply "C" <dont respond.com> writes:
 sometimes where methods doesn't (public static void main LOL...). For

 This "everything is an object" approach is an
 ideal.

Not for me.

I think he said it is an ideal, not it IS ideal.
 I also would love to have a nice string object with tons of useful methods
 (my absolute favourite one is Szymon Stefanek's KVIrc irc client string
 class).

Me too a good string class I think should be part of std. Ill go look up KVIrc , maybe we can recreate it.
 Since D supports templates I'm pretty sure a nice container library will

 a part of std shortly, there is already people working on it on this

I hope so, the 4 / 5 months I've been hear I've seen alot of talk, and alot of code but no organization or collobaration, and all our (my ?) pleas go unheard, its really really frusturating.
What is,  again, the advantage of that compared to having those functions

 module

Good point, for me coming from C++ I didn't really regocnize the power of modules as more than just a name for the import. C "Juanjo Álvarez" <juanjux NOSPAMyahoo.es> wrote in message news:c0uila$2psn$1 digitaldaemon.com...
 Knaar wrote:


 The first thing I would like to critisize, however, is D's approach to
 objects. The thing I was most disappointed about was the lack of
 classes/objects being utilised in the std.* modules.

I don't have any problem with functions, they are useful and make sense sometimes where methods doesn't (public static void main LOL...). For example, I'm writing a port of almost all the Linux/Unix libc-API to D, mostly functions. Part of that API will be later wrapped in objects (terminal, socket-stream, process, pipe-stream, mmap-stream, etc) but part won't, because it has little sense to create an object just to make a directory (mkdir), to change the uid (setuid), or to put an environment

 (putenv) (and it would be pretty absurd to encapsulate fork() in an

 given his nature). Objects are nice and I use them all the time, but
 sometimes structs and functions just fits better.

 In Java everything
 *MUST* be an object.

I prefer choice.
 There is no such thing as stand-alone functions or
 methods, all functions are members of classes which in turn can be
 instantiated into objects.

Well, then tell me what's exactly the different between a class only containing static methods (and java have some of those) and a module just containing functions?
 This "everything is an object" approach is an
 ideal.

Not for me.
 I know, but it does have a lot of up-sides to it. Any Java,
 Smalltalk, Ruby, C#, etc programmer is usually absolutely obsessed with
 objects and would find the std.* library extremely inadiquate, if not
 flatly unusable.

std.* is very young, I'm pretty sure that with some time we all are going

 have a nice class library, but calling a library "flatly unusable" because
 it is not 100% object oriented is very short-sighted, IMHO.

 Now, I know there really isn't a huge need for a String class, but I


 still like the option of using one. The main reason being that char[] is
 mutable, while usually a implementation of String is immutable. This
 allows for a great deal of optimizations on strings, allowing duplicates
 to be eliminated easily.

I also would love to have a nice string object with tons of useful methods (my absolute favourite one is Szymon Stefanek's KVIrc irc client string class).
 Vectors and Hashtables are totally unwarented
 though.

Since D supports templates I'm pretty sure a nice container library will

 a part of std shortly, there is already people working on it on this

 Also, I'm not sure if you can do this (I don't think you can) but the
 ability to have a class contain C methods. For example:

 class FileMethods {
 extern (Windows):
 public:
 HANDLE CreateFileA(...);
 HANDLE CreateFileW(...);
 }

 That way, those of us bent on never having any stand-alone methods can
 wrap these methods in classes. This prevents the need to write wrapper
 methods that just call the C method.

Sorry if I sound to harsh but that would be stuuuuuuuuuuupid. What is, again, the advantage of that compared to having those functions in a

 FileFunctions if wrapping them in a file class doesn't make sense?

Feb 17 2004
parent reply Juanjo =?ISO-8859-15?Q?=C1lvarez?= <juanjux NOSPAMyahoo.es> writes:
C wrote:

 I also would love to have a nice string object with tons of useful
 methods (my absolute favourite one is Szymon Stefanek's KVIrc irc client
 string class).

Me too a good string class I think should be part of std. Ill go look up KVIrc , maybe we can recreate it.

Then also look at Qt strings since the KviString inherit from it.
 Since D supports templates I'm pretty sure a nice container library will

 a part of std shortly, there is already people working on it on this

I hope so, the 4 / 5 months I've been hear I've seen alot of talk, and alot of code but no organization or collobaration, and all our (my ?) pleas go unheard, its really really frusturating.

We should setup a wiki somewhere, just a page listing who is working in what so we avoid dupplicated efforts and can at least get a pointer to the people working on every project. The ideal would be to have a CVS setup somewhere including all the phobos library, but I don't know if Walter wants phobos development to be so "open" at this stage. A new newsgroups group (D.Phobos) would algo be nice so people can publish patches to the libs that Walter could handle easily (a newgroup is not a bad CMS after all!).
Feb 18 2004
parent reply "C" <dont respond.com> writes:
 We should setup a wiki somewhere, just a page listing who is working in

 so we avoid dupplicated efforts and can at least get a pointer to the
 people working on every project. The ideal would be to have a CVS setup
 somewhere including all the phobos library, but I don't know if Walter
 wants phobos development to be so "open" at this stage. A new newsgroups
 group (D.Phobos) would algo be nice so people can publish patches to the
 libs that Walter could handle easily (a newgroup is not a bad CMS after
 all!).

We have http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage which actually works pretty well. We've been asking for a D.phobos forever prolly not happening , there is a phobos Page under Folders/Projects , it would be a good place to start. C "Juanjo Álvarez" <juanjux NOSPAMyahoo.es> wrote in message news:c0vk27$1e30$1 digitaldaemon.com...
 C wrote:

 I also would love to have a nice string object with tons of useful
 methods (my absolute favourite one is Szymon Stefanek's KVIrc irc



 string class).

Me too a good string class I think should be part of std. Ill go look


 KVIrc , maybe we can recreate it.

Then also look at Qt strings since the KviString inherit from it.
 Since D supports templates I'm pretty sure a nice container library



 be
 a part of std shortly, there is already people working on it on this

I hope so, the 4 / 5 months I've been hear I've seen alot of talk, and alot of code but no organization or collobaration, and all our (my ?) pleas go unheard, its really really frusturating.

We should setup a wiki somewhere, just a page listing who is working in

 so we avoid dupplicated efforts and can at least get a pointer to the
 people working on every project. The ideal would be to have a CVS setup
 somewhere including all the phobos library, but I don't know if Walter
 wants phobos development to be so "open" at this stage. A new newsgroups
 group (D.Phobos) would algo be nice so people can publish patches to the
 libs that Walter could handle easily (a newgroup is not a bad CMS after
 all!).

Feb 18 2004
parent reply Juanjo Álvarez <juanjux yahoo.es> writes:
In article <c10em5$2tem$1 digitaldaemon.com>, C says... 
 
We have

works pretty

happening , there

good place to start.

http://www.prowiki.org/wiki4d/wiki.cgi?Phobos Now it needs a more visible link on the front page and people not called "Juanjo Álvarez" actually registering his projects there ;) (and people in this newsgroups telling people to use it).
Feb 18 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Juanjo Álvarez" <juanjux yahoo.es> wrote in message
news:c10vbn$nqd$1 digitaldaemon.com...
 In article <c10em5$2tem$1 digitaldaemon.com>, C says...

We have

works pretty

happening , there

good place to start.

http://www.prowiki.org/wiki4d/wiki.cgi?Phobos Now it needs a more visible link on the front page and people not called "Juanjo Álvarez" actually registering his projects there ;) (and people in this newsgroups telling people to use it).

And this has saved us all some effort already! I had planned the other day to write an argument parser, and I see you've done one. Bravo! I look forward to using it. :)
Feb 18 2004
parent Juanjo Álvarez <juanjux yahoo.es> writes:
In article <c11buc$1bt2$1 digitaldaemon.com>, Matthew says... 
 
And this has

to write an

Me too! I was about to implement an object oriented mmap module until I've seen you've already taken the task. Nice :)
Feb 19 2004
prev sibling next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <c0uila$2psn$1 digitaldaemon.com>, Juanjo =?ISO-8859-15?Q?=C1lvarez?=
says...

 Also, I'm not sure if you can do this (I don't think you can) but the
 ability to have a class contain C methods. For example:
 
 class FileMethods {
 extern (Windows):
 public:
 HANDLE CreateFileA(...);
 HANDLE CreateFileW(...);
 }


Yes you can.
 
 That way, those of us bent on never having any stand-alone methods can
 wrap these methods in classes. This prevents the need to write wrapper
 methods that just call the C method.

Sorry if I sound to harsh but that would be stuuuuuuuuuuupid.

no it's not. (hopefully that is a simplified example just to illustrat the idea)
 What is,
again, the advantage of that compared to having those functions in a module
FileFunctions if wrapping them in a file class doesn't make sense?

You have none?... Once I didn't get why a TV commercial changed it's voice off. I knew nothing of the business. When I met guy from a marketing company a asked him and he come up with 6 different reasons on the spot. read any basic OO introduction. of course this is not the place to have a "OO / procedural / functional / whatever" war. Ant
Feb 18 2004
next sibling parent Ant <Ant_member pathlink.com> writes:
In article <c10gbi$30gk$1 digitaldaemon.com>, Ant says...

Yikes, sorry about the spelling. Ant
Feb 18 2004
prev sibling parent reply Juanjo Álvarez <juanjux yahoo.es> writes:
In article <c10gbi$30gk$1 digitaldaemon.com>, Ant says... 
 
try 
{ 
 
You have

 
Once I didn't get why a TV commercial changed it's voice off. 
I

When I met guy from a marketing company a asked

up with 6 different reasons on the spot. 
 
read any basic

I don't need it, I do OO programming in my work (sometimes in Java BTW and sometimes on other OO languages) and I do OO programming in my free-time pet projects so I know what I'm speaking about. Classes and objects are the right solution to a lot of problems, but they are not _always_ the best solution to _any_ given problem like the original poster suggests and saying otherwise is just religion (BTW you have not given any good reason of why wrapping static functions in a static class is so _evidently_ superior to grouping them in a module).
of course this is not the place to have a
"OO / procedural / functional / whatever" war. 

No, it is not, and anyway if you're confident on knowing the truth about this pure OO against mixed paradigm question, I'm also and we're not surely going to change our opinions just throwing axes here so... } catch (ParadigmFlameWarException e) { e.ignore(); } finally { Cheers, Juanjo }
Feb 18 2004
parent "davepermen" <davepermen hotmail.com> writes:
the trick is, that way C++/C interfaces (COM and similar) are directly
mapable to D interfaces.

thats a big +, not?

"Juanjo Álvarez" <juanjux yahoo.es> schrieb im Newsbeitrag
news:c10sh6$j7g$1 digitaldaemon.com...
 In article <c10gbi$30gk$1 digitaldaemon.com>, Ant says...

 try
 {

You have

Once I didn't get why a TV commercial changed it's voice off.
I

When I met guy from a marketing company a asked

up with 6 different reasons on the spot.

read any basic

I don't need it, I do OO programming in my work (sometimes in Java BTW and sometimes on other OO languages) and I do OO programming in my free-time pet projects so I know what I'm speaking about. Classes and objects are the right solution to a lot of problems, but they are not _always_ the best solution to _any_ given problem like the original poster suggests and saying otherwise is just religion (BTW you have not given any good reason of why wrapping static functions in a static class is so _evidently_ superior to grouping them in a module).
of course this is not the place to have a
"OO / procedural / functional / whatever" war.

No, it is not, and anyway if you're confident on knowing the truth about

 pure OO against mixed paradigm question, I'm also and we're not surely

 to change our opinions just throwing axes here so...

 } catch (ParadigmFlameWarException e)
 {
 e.ignore();
 } finally {
 Cheers,
 Juanjo
 }

Feb 18 2004
prev sibling parent "Jeroen van Bemmel" <someone somewhere.com> writes:
"Juanjo Álvarez" <juanjux NOSPAMyahoo.es> wrote in message
news:c0uila$2psn$1 digitaldaemon.com...
 Knaar wrote:


 The first thing I would like to critisize, however, is D's approach to
 objects. The thing I was most disappointed about was the lack of
 classes/objects being utilised in the std.* modules.


Good thing about modules: you can remove them and implement your OOwn!
 I don't have any problem with functions, they are useful and make sense
 sometimes where methods doesn't (public static void main LOL...). For
 example, I'm writing a port of almost all the Linux/Unix libc-API to D,
 mostly functions. Part of that API will be later wrapped in objects
 (terminal, socket-stream, process, pipe-stream, mmap-stream, etc) but part
 won't, because it has little sense to create an object just to make a
 directory (mkdir), to change the uid (setuid), or to put an environment

 (putenv) (and it would be pretty absurd to encapsulate fork() in an

 given his nature). Objects are nice and I use them all the time, but
 sometimes structs and functions just fits better.

Sounds like you've been living in a procedural world lately, don't let it affect the OO parts of your brain too much ;)
Feb 18 2004
prev sibling next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Knaar wrote:

In Java everything *MUST* be an object.

fully OO language go to smalltalk. -- -Anderson: http://badmama.com.au/~anderson/
Feb 17 2004
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
"Knaar" <Knaar_member pathlink.com> wrote in message
news:c0u870$29fj$1 digitaldaemon.com...
| This be my first post. First of all, I have to rant and rave about how much I
| like D. I read someone posted that there's "no original concepts" in D but
that
| to me is totally irrelevant. Experiemental languages with blow-your-mind
| concepts are rarely practical to use. I like D's amalgamation of useful and
| practical features from a veriety of languages.

Cool! welcome.

| The first thing I would like to critisize, however, is D's approach to
objects.
| The thing I was most disappointed about was the lack of classes/objects being
| utilised in the std.* modules. In Java everything *MUST* be an object. There
is
| no such thing as stand-alone functions or methods, all functions are members
of
| classes which in turn can be instantiated into objects. This "everything is an
| object" approach is an ideal, I know, but it does have a lot of up-sides to
it.
| Any Java, Smalltalk, Ruby, C#, etc programmer is usually absolutely obsessed
| with objects and would find the std.* library extremely inadiquate, if not
| flatly unusable.

The biggest items missing are containers (being worked on) and a GUI toolkit
(several in progress). And I'm in the camp that the GUI toolkit doesn't
belong in the standard library. With those D will become extremely usable.
The use of functions in std.* means all those calls are non-virtual (which
is a small performance boost over virtual dispatching). In Java the equivalent
would be static functions and there isn't much difference between typing
"classname.func(...)" and "modulename.func(...)".

| Now, I know there really isn't a huge need for a String class, but I would
still
| like the option of using one. The main reason being that char[] is mutable,
| while usually a implementation of String is immutable. This allows for a great
| deal of optimizations on strings, allowing duplicates to be eliminated easily.

If you want a string class for interning then it can be done "by hand" (no
need for a class). Just write a function "stringpool.intern" that takes a
char[] and interns it and returns the resulting char[]. Mutability is
then the responsibility of the programmer (same with any object that
is treated by reference). Given that std.string functions are "copy on write"
this means strings are fast if you don't modify them.
On the topic of string classes, it would be a fun experiment to wrap an
object around
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/cordh.txt
With overloading [] it could behave similarly to a D array. This would be
a neat little utility.
Feb 18 2004
parent "Nam" <dreamweaver mail15.com> writes:
Knaar ,when D is a very young language and perhap you don't look to D spec
and/or don't look at this:
http://www.digitalmars.com/d/comparison.html
which D vs C/C++/C# and Java ( which I have teleport all of D sites to my hd
for reading offline , sorry for that )
D syntax somewhere like C#/C++ when inherite by A : B and use "interface" +
plus "import" packages .
So D will be a mixture from C++/C# and Java also combine all strengths of
those languages.
Why do D not have a String class or any needed class ? Because it's not
implemented ( or wrapper , or adapt , evrything you call ).
 BTW, you can implement it , of course .
I have seen some project which wrap all kind of GUI to packages and you can
reach one of them at
http://int19h.tamb.ru/projects.html
Everything in Java not object like base datatype as int,boolean , char and
etc ...If my mind right , auto-boxing have just implemented in Tiger .
So we don't suprise when in D has something not object . They ( and you)
haven't implemented yet , not D :).
I really like Java , but the downside of it is it's speed . When I reach D ,
wow , I see that it's the language what I dream of .
Powerful , OO paradigm like my favorite pet ( Java ) and don't restrict in
Sandbox  , wow ;) .
The main reason don't use OO in std , cause the time and strength of D. When
you write Direct X code in your C# app , the class haven't auto-implemented
. M$ have implemented for you in C# ( and not in C++ ) .So please don't
blame at poor st.* packages :)  . It's not implemented yet , you can wrap it
to a System packages , if you want .
 The main reason is D keep C++ not-fully OO sides cause D is successor of
C++ and C++ is successor of C .
I'd really don't appreciate the idea of multi-inheritance and operator
overloading cause I don't need it and never use it ;) ( A Java guy I am )
But when D coders must use the strength from Windows APIs or Linux APIs (
Linux build on C hmm)  +plus speed , they must need it and it's the fastest
way , faster than JNI and don't deal with more troubles in JNI .
If you want class , just wrap it. If you want Tiger generic , use template
:). If you wanna do "import" instead "using" ,use D and Java :)
Just my 2 cents
Regards,
Nam

"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:c0vqrs$1p44$1 digitaldaemon.com...
 "Knaar" <Knaar_member pathlink.com> wrote in message
 news:c0u870$29fj$1 digitaldaemon.com...
 | This be my first post. First of all, I have to rant and rave about how

 | like D. I read someone posted that there's "no original concepts" in D

 that
 | to me is totally irrelevant. Experiemental languages with blow-your-mind
 | concepts are rarely practical to use. I like D's amalgamation of useful

 | practical features from a veriety of languages.

 Cool! welcome.

 | The first thing I would like to critisize, however, is D's approach to
 objects.
 | The thing I was most disappointed about was the lack of classes/objects

 | utilised in the std.* modules. In Java everything *MUST* be an object.

 is
 | no such thing as stand-alone functions or methods, all functions are

 of
 | classes which in turn can be instantiated into objects. This "everything

 | object" approach is an ideal, I know, but it does have a lot of up-sides

 it.
 | Any Java, Smalltalk, Ruby, C#, etc programmer is usually absolutely

 | with objects and would find the std.* library extremely inadiquate, if

 | flatly unusable.

 The biggest items missing are containers (being worked on) and a GUI

 (several in progress). And I'm in the camp that the GUI toolkit doesn't
 belong in the standard library. With those D will become extremely usable.
 The use of functions in std.* means all those calls are non-virtual (which
 is a small performance boost over virtual dispatching). In Java the

 would be static functions and there isn't much difference between typing
 "classname.func(...)" and "modulename.func(...)".

 | Now, I know there really isn't a huge need for a String class, but I

 still
 | like the option of using one. The main reason being that char[] is

 | while usually a implementation of String is immutable. This allows for a

 | deal of optimizations on strings, allowing duplicates to be eliminated

 If you want a string class for interning then it can be done "by hand" (no
 need for a class). Just write a function "stringpool.intern" that takes a
 char[] and interns it and returns the resulting char[]. Mutability is
 then the responsibility of the programmer (same with any object that
 is treated by reference). Given that std.string functions are "copy on

 this means strings are fast if you don't modify them.
 On the topic of string classes, it would be a fun experiment to wrap an
 object around
 http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/cordh.txt
 With overloading [] it could behave similarly to a D array. This would be
 a neat little utility.

Feb 20 2004
prev sibling parent Marco A <Marco_member pathlink.com> writes:
The first thing I would like to critisize, however, is D's approach to objects.
The thing I was most disappointed about was the lack of classes/objects being
utilised in the std.* modules. In Java everything *MUST* be an object. There is
no such thing as stand-alone functions or methods, all functions are members of
classes which in turn can be instantiated into objects. This "everything is an
object" approach is an ideal, I know, but it does have a lot of up-sides to it.
Any Java, Smalltalk, Ruby, C#, etc programmer is usually absolutely obsessed
with objects and would find the std.* library extremely inadiquate, if not
flatly unusable.

huh? so we want fake Math objects wrapping sine, cosine, etc functions? The Functional Programming folks would argue everything should be a function. Purists belong in academia not in real-life programming.
Feb 20 2004