Do you really want one of the standard D libraries to be all about accessing .ZIP files?  Sure, .ZIP files are fairly common today, but for how long? Does this really belong in the core D RTL spec?  It probably won't fit on an embedded system.

Also I dislike having to   "import object;"  in order to declare  "class foo : object {}".   Maybe object could just always be available for inheritance declarations.

I don't like the proposed name of the "File" import library.  It would conflict with user classes called File.  I'd call it module Fileio or something, since it may contain a class called file.  Ditto for the Date module.  Maybe this isn't as big a problem as I'm making it out to be.

Sean

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9taju0$1h17$1@digitaldaemon.com...

> Do you really want one of the standard D libraries to be all about
accessing
> .ZIP files?  Sure, .ZIP files are fairly common today, but for how long? Does this really belong in the core D RTL spec?  It probably won't fit on
an
> embedded system.

Maybe make it one of those "strongly encouraged" things to do?
Not required, but you can be sure it's supported wherever possible.

Besides, unless M$ decides that there's a better alternative to ZIP and makes the functionality built-in into next version of Windoze, I doubt end-users will want to move from ZIP to something else, even if this something compresses five times better and twice faster =)

> Also I dislike having to   "import object;"  in order to declare  "class
foo
> : object {}".   Maybe object could just always be available for
inheritance
> declarations.

Well since the default base class is always Object, I believe that the module that contains it is actually imported implicitly.

> I don't like the proposed name of the "File" import library.  It would conflict with user classes called File.  I'd call it module Fileio or something, since it may contain a class called file.  Ditto for the Date module.  Maybe this isn't as big a problem as I'm making it out to be.

I personally would say that I'd like a more generic "Stream" library, containing implementations not only for simple files, but maybe also for memory streams (TMemoryStream in Delphi), and, possibly, sockets.

"Sean L. Palmer" wrote:
> 
> Do you really want one of the standard D libraries to be all about accessing .ZIP files?  Sure, .ZIP files are fairly common today, but for how long? Does this really belong in the core D RTL spec?

I'd be surprised if ZIP files weren't still around in 5 years. But then, I'd be surprised if Unix wasn't still around in 5 years.

I would, however, make a case for generalizing the standard compression/decompression library, so that:

- ZIP and ZLib were optional codecs

- Developers can easily write their own codecs while using
  standardized APIs to read/write compressed data

- The compression/decompression APIs were suitable for
  operation in limited memory environments, streaming the
  compressed data to/from the disk/other-IO-device in small
  chunks, and in memory-rich environments, doing the whole
  compression/decompression in memory and reading/writing
  all at once.

> It probably won't fit on an
> embedded system.

I'd presume you can pick and choose which library components get incorporated into a D app. The same argument could be made against disk IO support or networking.

-RB