daniel.keep.lists at gmail.com
Sat May 23 05:21:05 PDT 2009
Andrei Alexandrescu wrote:
> * std.base64: doesn't deserve a separate module
The joys of a flat module hierarchy: it has to go *somewhere*. :P
> * std.conv: define operations to stream data out and in in binary and
> text formats.
What do you mean by "stream data"? Are we talking serialisation?
> * std.date: unnecessarily clunky and low-level. Also, somehow Walter
> thinks that std.dateparse has absolutely nothing to do with date.
My PhD involves writing a simulator, and it's used in some cases to
model historical events. As in, before 1980. I needed a little Python
script to take output in one format and dump it into a database.
That's when I found out that Python's date API is absolutely
pants-on-head retarded; it can't cope with dates before the UNIX epoch;
it just dies.
Every single Python library I could find for working with dates was
broken in the same way. It's like everyone seemed to think the universe
began with the invention of UNIX.
I ended up porting Phobos' date parsing and formatting code to Python.
> * std.metastrings: I hate the name. Merge into std.string using ctfe
How do you plan to do that? The problem with CTFE at the moment is that
code which works in CTFE is usually VERY suboptimal, while optimal code
doesn't run in CTFE.
So you end up with two functions for everything. I usually either end
up stuffing the string functions in separate modules or appending
"_ctfe" to all CTFE-compatible functions.
> * std.socket, std.socketstream: We need a real networking library.
> * std.variant: add dynamic method invocation capabilities
Any idea what you'll do here? Will (TypeInfo|ClassInfo).getMembers be
implemented, or will you be generating shims on instantiation?
> * std.xml: replace with something that moves faster than molasses.
I'd say to just steal from Tango. Their parsers seem to more or less
utterly destroy everything else in terms of speed.
In one test, Tango's PullParser is almost 100 times faster than std.xml!
Hell, you could refactor PullParser to have a range interface if you
wanted to. :D
> * std.zip: rewrite
Good luck with that. The Zip format sucks like a battery of Dyson's
hooked up in series to form some sort of ultimate sucking machine.
APPNOTE doesn't help, either. It's always nice to have a format spec
which specifies that you can have multiple redundant copies of the same
information which can DIFFER, and then doesn't define which one is
canonical or if it's even allowed.
That and I swear Tango's Zip module is cursed. I'm trying to close some
tickets on it, and I'm getting segfaults in places where it should be
impossible to get segfaults, plus when I try to debug it, the debugger
More information about the Digitalmars-d