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.

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

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

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?

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/

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

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

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

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

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