• "Sean L. Palmer" <spalmer iname.com> Nov 19 2001
• "Pavel Minayev" <evilone omen.ru> Nov 19 2001
• Russell Borogove <kaleja estarcion.com> Nov 19 2001

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


 .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


 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


 : object {}".   Maybe object could just always be available for


 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