Georg Wrede wrote:

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

I'm not sure whether it's even a goal to have Phobos warning-free ?


The code does tend to look silly, with the cast() and everything.

	ubyte fill = cast(ubyte) (value ? 0xFF : 0);

But the workarounds for the assert and the boolean ops are the worst.

   // returns true if end of stream is reached, false otherwise
-  bit eof() { return position() == size(); }
+  bit eof() { return cast(bit) (position() == size()); }

Of course, it does catch a couple of real bugs - along with the false.

--anders

Anders F Björklund wrote:
> The code does tend to look silly, with the cast() and everything.
> 
>     ubyte fill = cast(ubyte) (value ? 0xFF : 0);

What if there was a version of malloc that fills with 0xFF instead of 0x00? It would be handy and fast for both strings and floats.

> But the workarounds for the assert and the boolean ops are the worst.

I've given up talking about the booleans. :-)

"Anders F Björklund" <afb@algonet.se> wrote in message news:d33pun$2ord$1@digitaldaemon.com...
> 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...

ok. It is unusual to single out a single C function for importing everywhere - especially if D also has writef that we are touting as an improved printf. But is there an argument for removing it besides aesthetics? I'm not arguing that isn't a good reason - I just want to know if it's the only reason.

>> Also, what's the patch you are referring to?
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3170
>
> --anders

I think more than just that patch will be required to remove Object.print() (at least in dmd-120). Here's the result of grepping for "print(" in src/phobos that look like they refer to Object.print:

./internal/dmain2.d:    o.print();
./internal/object.d:    void print()
./internal/object.d:    void print()
./object.d:    void print();
./object.d:    void print();
./std/conv.d:       debug(conv) e.print();
./std/conv.d:       debug(conv) e.print();
./std/conv.d:       debug(conv) e.print();
./std/conv.d:       debug(conv) e.print();
./std/conv.d:       debug(conv) e.print();
./std/conv.d:       debug(conv) e.print();
./std/conv.d:       debug(conv) e.print();
./std/conv.d:       debug(conv) e.print();
./std/format.d: //ti.print();
./std/loader.d:                x.print();
./std/outofmemory.d:    void print()
./std/switcherr.d:    void print()
./std/thread.d:     o.print();
./std/thread.d:     o.print();
./std/zip.d:    void print()
./std/zip.d:    void print()

Walter wrote:

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

Maybe making (static?) member would lead to having both features: having all
functionality in one place (one class) and convenience.

Something like:
 void[] buf = File.MakeArrayFromFile("foo");
or:
 void[] buf = (new File("foo")).convertToArray();
or:
 just rearranging current modules to have whole "file functionality" in one
place.

I'm just telling what's wrong IMHO - it's much easier than tell what to do to make things better. :)
-- 
Dawid Ciężarkiewicz | arael
jid: arael@fov.pl

Ben Hinkle wrote:
> What is wrong with Phobos? (this is not a rhetorical question)

Phobos needs a concise and throughly documented exception hierarchy. I currently have to grep the Phobos sources to get a list of possible exceptions. And even that is pretty difficult since some of the names end with "Exception", some with "Error" and some don't have a "exceptionish" name at all.

I would really like to have an exception hierarchy ripped from Java or .NET BCL. I particulary yearn for a standard:

  ArgumentException(char[] msg, char[] argName)

Well, actually either that or rework DbC so that:

* contracts throw an InException instead of an AssertError
  like they should

* the InException instance holds the name of the invalid argument
  and a possible description given in the assert statement as such:

  assert (x > 0, "x must be positive");

Since I'm pretty confident that that can't (won't) be done, not even for 2.0, I just suggest including ArgumentException and friends in Phobos. Possibly include even a (.NET BCL'ish) Debug class with methods like

  writeLine(char[] msg);
  assert(bool condition, char[] msg);
  etc...

Oh, and I also hate std.string.toString since it clashes with Object.toString all the time. Rename one of them please.

"Niko Korhonen" <niktheblak@hotmail.com> wrote in message news:d35fvv$1u5b$1@digitaldaemon.com...
> Ben Hinkle wrote:
>> What is wrong with Phobos? (this is not a rhetorical question)
>
> Phobos needs a concise and throughly documented exception hierarchy. I currently have to grep the Phobos sources to get a list of possible exceptions. And even that is pretty difficult since some of the names end with "Exception", some with "Error" and some don't have a "exceptionish" name at all.
>
> I would really like to have an exception hierarchy ripped from Java or .NET BCL. I particulary yearn for a standard:
>
>   ArgumentException(char[] msg, char[] argName)
>
> Well, actually either that or rework DbC so that:
>
> * contracts throw an InException instead of an AssertError
>   like they should
>
> * the InException instance holds the name of the invalid argument
>   and a possible description given in the assert statement as such:
>
>   assert (x > 0, "x must be positive");
>
> Since I'm pretty confident that that can't (won't) be done, not even for 2.0, I just suggest including ArgumentException and friends in Phobos.

Good point. Some standard exceptions would help alot. I'm not so sure about the DbC suggestion since contracts aren't compiled in release mode but presumably one would want argument checking always. I'll start a new thread requesting ideas for standard exceptions. I'll include ArgumentException as an example.

> Possibly include even a (.NET BCL'ish) Debug class with methods like
>
>   writeLine(char[] msg);
>   assert(bool condition, char[] msg);
>   etc...

Sounds nice. I'm sure people have rolled their own Debug-like classes (I know I did for MinWin to print debug info to a log file).

> Oh, and I also hate std.string.toString since it clashes with Object.toString all the time. Rename one of them please.

I think this is the second time this was suggested. It would be nice to rethink the names. Is the .toString solution really that bad?

Ben Hinkle wrote:
> "Anders F Björklund" <afb@algonet.se> wrote in message news:d33pun$2ord$1@digitaldaemon.com...
> 
>>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...
> 
> 
> ok. It is unusual to single out a single C function for importing everywhere - especially if D also has writef that we are touting as an improved printf. But is there an argument for removing it besides aesthetics? I'm not arguing that isn't a good reason - I just want to know if it's the only reason.

I've had (probably just cosmetic, but anyway) name clash problems (a while ago now) when using a C library that had it's own printf. And I where using writef in the D code.

Lars Ivar Igesund