What is wrong with Phobos? (this is not a rhetorical question)

In recent threads several people have mentioned phobos isn't ready for 1.0 (myself included) so I'd like to get the issues out into the open. Some recent threads about std.format, std.mmfile and exceptions are the kinds of thing I have in mind. General comments like "it sticks" aren't useful but more specific comments like "foo is redundant with blah" or "std.what.ever has the following bug on Linux" would help narrow down the issues. Gaps in functionality that people feel strongly about would also be good to bring up.

It is not cool at all to write std.string.toString(foo) (kinda a long name for something that should be called atoc or something:) anytime you need to convert foo to string. It isn't cool to wrap std.string.toString for every type it is avalable neither...

It sucks when you import new phobos module at some point and all your previous code won't compile anymore because of conflicts (examples std.string/std.regexp: split,replace,etc and std.string/std.c.stdlib: atoi)

Functions/classes it provides are not sufficient. I think it should cover @least standart c lib so we don't need calling any c api directly...

There are some functions (isfile) that chashes if file doesn't exists or some other condition. I suppose they throw exception or something. But I think this way: I don't like exceptions (I'm addicted to c error handling :) so when file doesn't exists it is clear to me that isfile should return false, because obviously the path is not file if it doesn't exists. So when if don't want to check if path exists and I just want to know if it is file I call isfile(foo) and I don't want it to crash. Adding try/catch complicates this simple call unnecessary... I'm not sure if this point conflicts with D error handling policy...

In article <d2um1i$2ld2$1@digitaldaemon.com>, Ben Hinkle says...
>
>What is wrong with Phobos? (this is not a rhetorical question)
>
>In recent threads several people have mentioned phobos isn't ready for 1.0 (myself included) so I'd like to get the issues out into the open. Some recent threads about std.format, std.mmfile and exceptions are the kinds of thing I have in mind. General comments like "it sticks" aren't useful but more specific comments like "foo is redundant with blah" or "std.what.ever has the following bug on Linux" would help narrow down the issues. Gaps in functionality that people feel strongly about would also be good to bring up.
>
>

"bobef" <bobef_member@pathlink.com> wrote in message news:d2v0f8$5p$1@digitaldaemon.com...
> It is not cool at all to write std.string.toString(foo) (kinda a long name
> for
> something that should be called atoc or something:) anytime you need to
> convert
> foo to string. It isn't cool to wrap std.string.toString for every type it
> is
> avalable neither...

What was std.string.toString clashing with? If it's the Object.toString the common technique to get the std.string.toString is to use .toString (note the leading "."). That technique should be put in a FAQ. It would be cool if we could write foo.toString when the type of foo is a builtin type as well as a struct or class. That would avoid D's weak overload rules.

> It sucks when you import new phobos module at some point and all your
> previous
> code won't compile anymore because of conflicts (examples
> std.string/std.regexp:
> split,replace,etc and std.string/std.c.stdlib: atoi)

Hmm. I agree that is annoying. And since std.string is imported so often these issues will come up fairly often. Maybe we could split up std.string into smaller pieces. It imports many modules itself.

> Functions/classes it provides are not sufficient. I think it should cover
> @least
> standart c lib so we don't need calling any c api directly...

Like what in particular would you like to see? I guess I don't mind calling the C api when it makes sense but looking at bringing in common functions would be a good idea.

> There are some functions (isfile) that chashes if file doesn't exists or
> some
> other condition. I suppose they throw exception or something. But I think
> this
> way: I don't like exceptions (I'm addicted to c error handling :) so when
> file
> doesn't exists it is clear to me that isfile should return false, because
> obviously the path is not file if it doesn't exists. So when if don't want
> to
> check if path exists and I just want to know if it is file I call
> isfile(foo)
> and I don't want it to crash. Adding try/catch complicates this simple
> call
> unnecessary... I'm not sure if this point conflicts with D error handling
> policy...

That seems reasonable to me. One can imagine isfile and isdir returning false when the target doesn't exist since indeed the target is not a file or directory. Otherwise you have to code it up like (exist(name) && isfile(name)) and that takes two GetFileAttributes/stat calls and just seems annoying.

I think that structure of Apache Portable Runtime
is what any practical application needs.
http://apr.apache.org/docs/apr/modules.html

APR is portable means that it includes definitions of
only "common denominator" for all supported platform.
So do Phobos.

I think that it should be two layers (rings) in the std:
a) "Phobos Core" - low level APR alike set and
b) "Phobos Mantle" - high level abstractions: classes, algorithms
    and templates.

version(Win32) { .... } version(linux) {}
shall be used only in "core" to allow to port all stuff
on various platforms easily.

IMHO of course.

Andrew.
http://terrainformatica.com

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d2v79t$7c7$1@digitaldaemon.com...
>I think that structure of Apache Portable Runtime
> is what any practical application needs. http://apr.apache.org/docs/apr/modules.html
>
> APR is portable means that it includes definitions of
> only "common denominator" for all supported platform.
> So do Phobos.
>
> I think that it should be two layers (rings) in the std:
> a) "Phobos Core" - low level APR alike set and
> b) "Phobos Mantle" - high level abstractions: classes, algorithms
>    and templates.

I like the planet motif :-)
Would they all live in the std package or would I as a user have to import
std.core.blah and import std.mantle.foo?

> version(Win32) { .... } version(linux) {}
> shall be used only in "core" to allow to port all stuff
> on various platforms easily.

That would be a nice goal. We could actually enforce that by defining Core as those packages that have version(OS) statements. I could imagine it could get somewhat arbitrary, though.

Andrew Fedoniouk wrote:
> I think that structure of Apache Portable Runtime
> is what any practical application needs.
> http://apr.apache.org/docs/apr/modules.html
> 
> APR is portable means that it includes definitions of
> only "common denominator" for all supported platform.
> So do Phobos.
> 
> I think that it should be two layers (rings) in the std:
> a) "Phobos Core" - low level APR alike set and
> b) "Phobos Mantle" - high level abstractions: classes, algorithms
>     and templates.
> 
> version(Win32) { .... } version(linux) {}
> shall be used only in "core" to allow to port all stuff
> on various platforms easily.
> 
> IMHO of course.

I tend to agree here.

Ben Hinkle wrote:

> What is wrong with Phobos? (this is not a rhetorical question)
> 
> In recent threads several people have mentioned phobos isn't ready for 1.0 (myself included) so I'd like to get the issues out into the open. Some recent threads about std.format, std.mmfile and exceptions are the kinds of thing I have in mind. General comments like "it sticks" aren't useful but more specific comments like "foo is redundant with blah" or "std.what.ever has the following bug on Linux" would help narrow down the issues. Gaps in functionality that people feel strongly about would also be good to bring up.

One naming convention, please.
isalpha() but toString() ?! IMHO Second should be used everywhere .

Remove all kinds of printf/writef using ("%i", ...) and such.

Whole Phobos looks like being only mixed C bindings and few additional classes. For me overall impression is terrible. Sorry to say so - but I would gladly see another Phobos - new, totally rewritten, better documented, where C bindings would be only delivered for convenience.

There are parts of Phobos that I used without bigger problems: Sockets, Threads. But writing to files for example was one big misunderstanding. Those read()s and write()s for internal use only ... - are they really necessary?

Printing in C++ was like:
file << intVar << " some text " << stringVar << floatVar;

in Phobos ... I still don't know good way. Documentation need to be improved - I don't from where I discovered information about std.stream.stdout . And more examples would be bless.

I strongly agree with Andrew Fedoniouk: Phobos should be splited in two parts: high and low level. And one day there must be some kind of STL.

Regards,
-- 
Dawid Ciężarkiewicz | arael
jid: arael@fov.pl

"Dawid Ciê¿arkiewicz" <arael@fov.pl> wrote in message news:d3188i$2o5p$1@digitaldaemon.com...
> Ben Hinkle wrote:
>
>> What is wrong with Phobos? (this is not a rhetorical question)
>>
>> In recent threads several people have mentioned phobos isn't ready for
>> 1.0
>> (myself included) so I'd like to get the issues out into the open. Some
>> recent threads about std.format, std.mmfile and exceptions are the kinds
>> of thing I have in mind. General comments like "it sticks" aren't useful
>> but more specific comments like "foo is redundant with blah" or
>> "std.what.ever has the following bug on Linux" would help narrow down the
>> issues. Gaps in functionality that people feel strongly about would also
>> be good to bring up.
>
> One naming convention, please.
> isalpha() but toString() ?! IMHO Second should be used everywhere .

good point.

> Remove all kinds of printf/writef using ("%i", ...) and such.

Where are these? I'm not sure which printf/writef you are referring to. Do you mean the various commented-out and/or verion'ed-out debugging printfs?

> Whole Phobos looks like being only mixed C bindings and few additional classes. For me overall impression is terrible. Sorry to say so - but I would gladly see another Phobos - new, totally rewritten, better documented, where C bindings would be only delivered for convenience.
>
> There are parts of Phobos that I used without bigger problems: Sockets, Threads. But writing to files for example was one big misunderstanding. Those read()s and write()s for internal use only ... - are they really necessary?

Which read/writes are you referring to? Some in std.file or std.stream?

> Printing in C++ was like:
> file << intVar << " some text " << stringVar << floatVar;
> in Phobos ... I still don't know good way.

If file is a Stream then I'd try something like
 file.writef(intVar," some text ", stringVar, floatVar);
or possibly if stringVar can contain % symbols you might need to do
 file.writef(intVar," some text %s", stringVar, floatVar);

> Documentation need to be improved
> - I don't from where I discovered information about std.stream.stdout .
> And
> more examples would be bless.

Agreed. The documentation is a reference document and has next to zero examples. We need either decent tutorials or just introductory explanations about what is in each module.

> I strongly agree with Andrew Fedoniouk: Phobos should be splited in two parts: high and low level. And one day there must be some kind of STL.
>
> Regards,
> -- 
> Dawid Ciê¿arkiewicz | arael
> jid: arael@fov.pl

Ben Hinkle wrote:
>> Remove all kinds of printf/writef using ("%i", ...) and such.
> 
> Where are these? I'm not sure which printf/writef you are referring to. Do you mean the various commented-out and/or verion'ed-out debugging printfs?

No, no. I'm not talking about how is Phobos implemented. That is non of my business. :D I'm talking about "from end-user-developer point of view". And such user shouldn't have to look at standard library code.

I mean that Object has static int printf(char* format, ...); member. That here http://www.digitalmars.com/d/phobos.html  printf still seems to be default and advised to use way of printing.

>> Whole Phobos looks like being only mixed C bindings and few additional classes. For me overall impression is terrible. Sorry to say so - but I would gladly see another Phobos - new, totally rewritten, better documented, where C bindings would be only delivered for convenience.
>>
>> There are parts of Phobos that I used without bigger problems: Sockets, Threads. But writing to files for example was one big misunderstanding. Those read()s and write()s for internal use only ... - are they really necessary?
> 
> Which read/writes are you referring to? Some in std.file or std.stream?

http://www.digitalmars.com/d/phobos.html sections: "std.outbuffer" and "std.stream". I can't see way to easily read float or int from text file, but there are tons of functions that are rather to low level for common user. Hiding them in documentation that makes first impression may be a good idea. Of course they should be described in deeper documentation.

Any:
int i,j;
file.scan(i).scan(j);
?

Maybe it's only fault of bad and outdated documentation, but good impression is worthless even in computer world. :)

>> Printing in C++ was like:
>> file << intVar << " some text " << stringVar << floatVar;
>> in Phobos ... I still don't know good way.
> 
> If file is a Stream then I'd try something like
>  file.writef(intVar," some text ", stringVar, floatVar);
> or possibly if stringVar can contain % symbols you might need to do
>  file.writef(intVar," some text %s", stringVar, floatVar);

I like that. Thanks.


Another thoughts:
std.time:
d_time begs for being a class. Almost every function takes as a first arg.
d_time t. And the name: d_time reminds me t_size and such ugliness from C.

std.date:
begs for being a class

std.file:
begs for being a class. And is realized as a class in std.stream. Why to
have both? Some aspects of std.file like isdir() should be moved into class
File and some - like mkdir() - to hmm... std.system or std.filesystem?

std.conv:
Can't this module be merged with std.string ?

etc. etc. etc.

I may be wrong in some aspects, but Phobos need more "class" keyword and lot of rearanging to make it look like one, monolyth and Object Orinted standard runtime library.
-- 
Dawid Ciężarkiewicz | arael
jid: arael@fov.pl

> Another thoughts:
> std.time:
> d_time begs for being a class. Almost every function takes as a first arg.
> d_time t. And the name: d_time reminds me t_size and such ugliness from C.

Do you mean std.c.time? That's the C API so there isn't much we can do about it. I suppose we can have a std.time with another API if it is significantly better.

> std.date:
> begs for being a class

Probably a struct would be better IMO. That way we could reduce naming clashes while keeping value/lightweight semantics. With opAdd and other arithmetic overloads the usefulness of aliasing d_time with long can be preserved. The functions should at least have a consistent naming scheme. Half the functions in std.date are CamelCaseWithFirstCaps and half are camelCaseWithFirstLower. Plus it looks like lots of the public functions in there aren't documented.

> std.file:
> begs for being a class. And is realized as a class in std.stream. Why to
> have both? Some aspects of std.file like isdir() should be moved into
> class
> File and some - like mkdir() - to hmm... std.system or std.filesystem?
>
> std.conv:
> Can't this module be merged with std.string ?
>
> etc. etc. etc.

Reasonable ideas.

> I may be wrong in some aspects, but Phobos need more "class" keyword and
> lot
> of rearanging to make it look like one, monolyth and Object Orinted
> standard runtime library.

The more suggestions the better!

> -- 
> Dawid Ciê¿arkiewicz | arael
> jid: arael@fov.pl