On Wed, 06 Apr 2005 23:34:08 +0200, Dawid Ciężarkiewicz <arael@fov.pl> wrote:
> 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.

Agreed.

> std.date:
> begs for being a class

Agreed.

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

Agreed.

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

Agree and Disagree. I think std.string should be split into modules focusing on certain tasks. "string" is a big area. Smaller modules focused on specific parts and a top module that imports the lot would be how I'd like it done.

So std.conv might be std.string.conv and focus on conversion to/from strings.

or alternately,
std.conv.string might handle conversions 'to' string
std.conv.int might handle conversions 'to' int
..etc..

The problem being "import std.conv;" won't get the lot, and re-opens the debate about this and how best to get "the lot" eg.

import std.conv.all;

--std\conv\all.d]--
import std.conv.a
import std.conv.b
..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.

The problem being while I agree with you, I am happy with a mix of OO and non-OO, where OO is used where appropriate, "begs for being a class", (as in std.time, d_time, etc).

Others want to be "pure OO" (Ant for example) or "pure non-OO" (no names spring to mind) and therefore phobos needs to be able to achieve all things in both paradigms.

Of course we want to avoid duplicating code/functionality, all that does is duplicate bugs and/or create inconsistency between the implementations.

So, where possible I think the OO should be built on the non-OO (provided no penalties are incurred) as it's generally agreed that doing it the other way round would bring performance penalties to non-OO.

This makes sense right down to the system compatibility layer, which is generally implemented in non-OO functions.

It may even be beneficial to emphasize the split in the library, eg.

std.oo.<etc>  <- OO
std.??.<etc>  <- non-OO
or
std.<etc>  <- non-OO

So, std.date would contain non-OO versions doing all the "hard-work" and std.oo.date would contain a class that imported and wrapped std.date.

Regan

"Dawid Ciê¿arkiewicz" <arael@fov.pl> wrote in message news:d31kkg$6mh$1@digitaldaemon.com...
> std.file:
> begs for being a class.

You make some good comments. But this one I have to disagree with. At one point it was a class, but there seemed to be no point. For example, if I want to read a file "foo":

    void[] buf = std.file.read("foo");

and I'm done. What purpose would a class provide?

>> std.date:
>> begs for being a class
>
> Probably a struct would be better IMO.

Heavens to Betsy - there's a Date struct in std.date already but it isn't documented and barely has any member functions at all. It seems like a good candidate for improvements and/or replacing d_time. One issue is that the existing Date is broken down into days, minutes, etc while d_time is a single long. I haven't thought about ways to reconcile those two. Plus another wrinkle is that std.dateparse is involved. Anyway, I tend to agree std.date could use some refactoring and/or documentation.

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

Something that has always seemed wierd to me is Thread.getThis(). The
function returns the current thread as a Thread object. The name "getThis"
seems like a joke - where I come from the phrase "get this" is used to set
up a punch line in a joke. A better name would be either currentThread() or
getCurrentThread() and I'd prefer if it wasn't static in Thread since it is
unlikely to clash and is more readable without the leading Thread prefix. So
for example today one would write
  Thread t = Thread.getThis();
and I'd prefer something like
  Thread t = getCurrentThread();

Ben Hinkle wrote:

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

MISSING FEATURES

- Phobos doesn't pass with warnings enabled (-Wall -Werror / -w)

- Some parts of the C99 standard library could still be missing ?

- There is no automatically generated documentation, like Doxygen
  (such documentation would also be up-to-date with the sources...)

- There should be three sub-libraries: RunTime, GC, and Phobos
  (or five, if zlib and recls should still be included as well)

- The Phobos documentation is not open nor free (a license issue)

BUILD ISSUES

- There is no .tar.gz version of DMD/Phobos with UNIX line-endings

- The Makefile for Linux (linux.mak) lacks a "make install" target

- The Makefile uses "make" instead of "$(MAKE)" and "$(MAKEFLAGS)"

- There is no "contracts-enabled" version of Phobos, for debugging

BUGS

- Object print/printf has already been beaten to death and patched,
  so I'm not sure that's an issue anymore (but it's still in DMD's ?)

- stdio only does output, and readf/unformat are broken due to lack
  of TypeInfo classes for pointers (i.e. the Mangle hack doesn't work)

- crc32.d / module crc should most likely be in std.crc32, or something

- std.system and std.compiler are not being used (Win NT 4.0 / DMD 0.0)

- std.loader is not very good, and was not even included in libphobos.a

LIMITATIONS

- Phobos is split on operating system (OS) instead of interface (API)
  This makes for a lot of redundancy on the various "Posix" platforms

- DMD Phobos does not recognize platforms other than X86/X86_64, even
  though the GDC Phobos does ? (this also affects the DMD front-end)

- There should be as few differences as possible between the Phobos
  from DMD and the Phobos from GDC, since they use version() anyway ?

- A few files still have licensing issues, see other thread here...
  There is no one single summary of the various copyright holders:

  Copyright (C) 2004-2005 by Digital Mars, www.digitalmars.com
  Copyright (C) 2004 Christopher E. Miller
  Copyright (c) 2001, 2002 Pavel "EvilOne" Minayev

  Copyright (C) 1991-1992, RSA Data Security, Inc. (md5)
  Copyright (C) 1995-2003 Jean-loup Gailly and Mark Adler (zlib)
  Copyright (C) 2002-2004, Synesis Software Pty Ltd. (recls)

EXTERNAL LIBS (etc.c)

- zlib is outdated (1.2.1, versus 1.2.2)
  Should offer a possibility to use the system zlib library instead ?

- etc.c.zlib (zlib.h translation) should be in std.c.zlib

- recls is outdated (1.2.1, versus 1.6.1)
  Maybe the C/C++ implementation of recls is better offered standalone ?

- std.recls's inline "extern(C)" could be in std.c.recls

CONTROVERSY

- "There is too much C stdlib in Phobos"

- "There is too little C++ STL in Phobos"

- "Phobos is not object-oriented enough"

- "The name Phobos is silly for a library"

- "Any changes to Phobos take too long"

- "Too centralized a development model"


Of course, some of my own comments are controversial too of course. :-)

I'm sure there are others, too ? I'm more worried about "bugs" in the
D language specification and in the D reference compiler. As it is now,
those either stop or complicate the development of D standard library ?

Did I mention the lack of a timetable or a roadmap, until a "release" ?
(a problem that it shares with the D language, and the D compiler too)
There is still quite a few organization problems with the D development.

But I thank Walter Bright for creating D, and making it Free Software.

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:d32vm6$1m62$1@digitaldaemon.com...
> Ben Hinkle wrote:
>
>> What is wrong with Phobos? (this is not a rhetorical question)
>
> MISSING FEATURES
>
> - Phobos doesn't pass with warnings enabled (-Wall -Werror / -w)

I imagine it fails on int-to-bit conversions and the like?

> - Some parts of the C99 standard library could still be missing ?

Did you have something particular in mind?

> - There is no automatically generated documentation, like Doxygen
>   (such documentation would also be up-to-date with the sources...)

It would be nice I suppose - but personally I rather get the API and behavior "right" first.

> - There should be three sub-libraries: RunTime, GC, and Phobos
>   (or five, if zlib and recls should still be included as well)

Do you mean three put together into phobos.lib/libphobos.a or do you mean three libraries? If you mean the former then it already is pretty much the case since the gc is in internal/gc/dmgc.lib. Plus I'm not sure what exactly distinguishes the RunTime from Phobos since Phobos is "the run-time library". Do you mean just the absolute bare minimum to compile void main(){}?

> - The Phobos documentation is not open nor free (a license issue)

ok

> BUILD ISSUES
>
> - There is no .tar.gz version of DMD/Phobos with UNIX line-endings

Doesn't your editor figure this out? Which editor do you use?

> - The Makefile for Linux (linux.mak) lacks a "make install" target

True that would be nice so that you don't have to copy libphobos.a by hand.

> - The Makefile uses "make" instead of "$(MAKE)" and "$(MAKEFLAGS)"
>
> - There is no "contracts-enabled" version of Phobos, for debugging

This would be nice - any template in Phobos instantiated in user code with debugging turned on needs debugging in phobos turned on. So right now to use and debug TArrayStream in user code they have to first recompile phobos.

> BUGS
>
> - Object print/printf has already been beaten to death and patched,
>   so I'm not sure that's an issue anymore (but it's still in DMD's ?)

When I was looking at the Exceptions/Errors I noticed that Object.print is used in dmain2 to print any uncaught exceptions to stdout before exiting. The only case I could think of where it be dangerous to replace print() with using toString()  was in outofmemory.d since toString would have to return a string and we'd have to be careful we don't use any memory. The answer there is that OutOfMemoryException (which currently is called OutOfMemory but that's another story) can return a string literal. So, anyway, I agree that uses of print() should be replaced with printf() and toString().

> - stdio only does output, and readf/unformat are broken due to lack
>   of TypeInfo classes for pointers (i.e. the Mangle hack doesn't work)
>
> - crc32.d / module crc should most likely be in std.crc32, or something

ok

> - std.system and std.compiler are not being used (Win NT 4.0 / DMD 0.0)

What do you mean by "not being used"? I assume you mean the version info. The Endian stuff in std.system is useful. I agree the std.compiler hard-coding the list of compilers into enums is not scalable at all - and it isn't even up to date :-)

> - std.loader is not very good, and was not even included in libphobos.a
>
> LIMITATIONS
>
> - Phobos is split on operating system (OS) instead of interface (API)
>   This makes for a lot of redundancy on the various "Posix" platforms
>
> - DMD Phobos does not recognize platforms other than X86/X86_64, even
>   though the GDC Phobos does ? (this also affects the DMD front-end)
>
> - There should be as few differences as possible between the Phobos
>   from DMD and the Phobos from GDC, since they use version() anyway ?
>
> - A few files still have licensing issues, see other thread here...
>   There is no one single summary of the various copyright holders:
>
>   Copyright (C) 2004-2005 by Digital Mars, www.digitalmars.com
>   Copyright (C) 2004 Christopher E. Miller
>   Copyright (c) 2001, 2002 Pavel "EvilOne" Minayev
>
>   Copyright (C) 1991-1992, RSA Data Security, Inc. (md5)
>   Copyright (C) 1995-2003 Jean-loup Gailly and Mark Adler (zlib)
>   Copyright (C) 2002-2004, Synesis Software Pty Ltd. (recls)

good stuff. The copyright issues would be good to unify.

> EXTERNAL LIBS (etc.c)
>
> - zlib is outdated (1.2.1, versus 1.2.2)
>   Should offer a possibility to use the system zlib library instead ?
>
> - etc.c.zlib (zlib.h translation) should be in std.c.zlib
>
> - recls is outdated (1.2.1, versus 1.6.1)
>   Maybe the C/C++ implementation of recls is better offered standalone ?
>
> - std.recls's inline "extern(C)" could be in std.c.recls
>
> CONTROVERSY
>
> - "There is too much C stdlib in Phobos"
>
> - "There is too little C++ STL in Phobos"
>
> - "Phobos is not object-oriented enough"
>
> - "The name Phobos is silly for a library"

Is "phobos" a pointer to a bunch of hobos? :-)

> - "Any changes to Phobos take too long"

I haven't had problems changing std.stream but then I haven't been making serious backwards-incompatible changes. I know other changes have either not happened or been promised but not appeared. I don't know the details but I hope those were due to process problems between Walter and the submitter and/or a mismatch of expectations about the focus of Walter's efforts the past year or more.

> - "Too centralized a development model"

I'm not that convinced there's been a sustained and public effort by people
to fix issues in phobos. I'm hoping that by getting the process down we can
send Walter solid, vetted changes that get in easily.
Knowing if Walter is willing to accept changes to phobos generally along the
lines in this and other threads would help.

> Of course, some of my own comments are controversial too of course. :-)
>
> I'm sure there are others, too ? I'm more worried about "bugs" in the D language specification and in the D reference compiler. As it is now, those either stop or complicate the development of D standard library ?

really? I'm not aware of any bugs that have stopped phobos changes.

> Did I mention the lack of a timetable or a roadmap, until a "release" ? (a problem that it shares with the D language, and the D compiler too) There is still quite a few organization problems with the D development.

It would make life easier knowing what to expect. It's impossible to tell what will come in the next release or the 1.0 release.

> But I thank Walter Bright for creating D, and making it Free Software.

absolutely.

> --anders

Ben Hinkle wrote:

>>- Phobos doesn't pass with warnings enabled (-Wall -Werror / -w)
> 
> I imagine it fails on int-to-bit conversions and the like?

Yeah, and int calculations to bytes - stuff like that...
(The C warnings are just one: pthread_mutexattr_settype)

I fixed all warnings for DMD 0.118, but since none of
it wen't into DMD 0.120 I won't bother doing so again.

>>- Some parts of the C99 standard library could still be missing ?
> 
> Did you have something particular in mind?

I will run a new diff against Sean Kelly's version, but there was some ?

http://home.f4.ca/sean/d/stdc.zip (haven't checked against DMD recently)

> Do you mean three put together into phobos.lib/libphobos.a or do you mean three libraries? If you mean the former then it already is pretty much the case since the gc is in internal/gc/dmgc.lib. Plus I'm not sure what exactly distinguishes the RunTime from Phobos since Phobos is "the run-time library". Do you mean just the absolute bare minimum to compile void main(){}?

Yes, I meant just like it is being done in the Ares project actually:

http://www.dsource.org/forums/viewtopic.php?t=459

>>- There is no .tar.gz version of DMD/Phobos with UNIX line-endings
> 
> Doesn't your editor figure this out? Which editor do you use?

It does, but I still get an extra meg of Windows cruft with the zip
download and I can't use any automated tools like "patch" and "diff" ?

I've done a small shell script to convert dmd.120.zip into dmd-0.120.tar.gz, but it would be simpler if Walter ran it...

>>- The Makefile for Linux (linux.mak) lacks a "make install" target
> 
> True that would be nice so that you don't have to copy libphobos.a by hand.

Installing the library is simple, I meant all the import modules...

(cd dmd/src/phobos; find -name '*.d' | grep -v internal | xargs tar c) |
       (cd $RPM_BUILD_ROOT%{phobosdir}; tar xv)

>>- There is no "contracts-enabled" version of Phobos, for debugging
> 
> This would be nice - any template in Phobos instantiated in user code with debugging turned on needs debugging in phobos turned on. So right now to use and debug TArrayStream in user code they have to first recompile phobos.

Actually, it needs "release turned off", to get the contracts.
Since "debugging turned on" is something else, it's a version...

>>- std.system and std.compiler are not being used (Win NT 4.0 / DMD 0.0)
> 
> What do you mean by "not being used"? I assume you mean the version info. The Endian stuff in std.system is useful. I agree the std.compiler hard-coding the list of compilers into enums is not scalable at all - and it isn't even up to date :-)

That's what I meant: "not up to date". The Endian enum is trivial...

>>I'm sure there are others, too ? I'm more worried about "bugs" in the
>>D language specification and in the D reference compiler. As it is now,
>>those either stop or complicate the development of D standard library ?
> 
> really? I'm not aware of any bugs that have stopped phobos changes.

I'm only aware of the various TypeInfo bugs myself, especially pointers.

--anders

> - Object print/printf has already been beaten to death and patched,
>   so I'm not sure that's an issue anymore (but it's still in DMD's ?)

More thoughts on this one. I can see why people want to remove Object.print
but what's the printf issue? Do people want to remove the printf declaration
in object.d?
Also, what's the patch you are referring to?
Finally, the documentation for object.d is wrong. printf is not a member
function of the class Object (among other issues). That needs updating
together with whatever happens to object.d

Anders F Björklund wrote:
> Ben Hinkle wrote:
> 
>>> - Phobos doesn't pass with warnings enabled (-Wall -Werror / -w)
>>
>>
>> I imagine it fails on int-to-bit conversions and the like?
> 
> 
> Yeah, and int calculations to bytes - stuff like that...
> (The C warnings are just one: pthread_mutexattr_settype)
> 
> I fixed all warnings for DMD 0.118, but since none of
> it wen't into DMD 0.120 I won't bother doing so again.

Hey, Anders, don't panic. I bet Walter's been busy with the compiler. I wouldn't be surprised if he's saved your warning fixes, and they'd appear as soon as he's into Phobos!

Ben Hinkle wrote:

>>- Object print/printf has already been beaten to death and patched,
>>  so I'm not sure that's an issue anymore (but it's still in DMD's ?)
> 
> More thoughts on this one. I can see why people want to remove Object.print but what's the printf issue? Do people want to remove the printf declaration in object.d?

It should be moved back to the std.c.stdio module, where it belongs...

> Also, what's the patch you are referring to?

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3170

--anders