www.digitalmars.com         C & C++   DMDScript  

D - D Class Library - Imports

reply "Sean L. Palmer" <spalmer iname.com> writes:
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
Nov 19 2001
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"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.
Nov 19 2001
prev sibling parent Russell Borogove <kaleja estarcion.com> writes:
"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
Nov 19 2001