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.

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


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.

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.

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, 

 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


lol! That is ridicoulous.



 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


be

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


forum.

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


in a

 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


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,

 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
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


 be

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


 forum.
 
 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


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!).


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






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

 be

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


 forum.

 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 Juanjo Álvarez <juanjux yahoo.es> writes:
In article <c10em5$2tem$1 digitaldaemon.com>, C says... 
 

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.


I've done some modifications,take a look:
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


 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.


 I've done some modifications,take a look:
 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


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! 
 
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


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. 
 
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


 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.

 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



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


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.


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.


What about int and float? These are not objects in java.  If you want a 
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.

| 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

for reading offline , sorry for that )

plus "import" packages .

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


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


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.



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 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.

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