My opinion is that neither should be in the 1.0 standard library, so we have freedom to have a proper competitive, tested, comprehensive implementation for 2.0, which will be maximally efficient, usable, comprehensible and robust. The C++ streams library only manages 1.5 / 4 there, and that took a long time to develop.

The same goes for GUI.

It may be that Mango ends up being the standard streams for Phobos, or std.stream, or a refactored of std.stream, or something entirely new.

Since std.stream is in there, I don't expect it to be taken out. But I do think that the above open-mindedness should be manifest in the community, and clearly expressed to all users, especially new ones.

D has the faculties to mean that we have the potential to have the best IO libraries in the C-family world. I hope it will be realised.



"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cbc1t0$6h7$1@digitaldaemon.com...
> In article <cbaj13$10pl$1@digitaldaemon.com>, Kris says...
> >
> >Mango.io could indeed be placed into Demios without issue, if you folks feel that's the right home for it. However, the point about mixing portions of libraries is a good one: sometimes a library must expose some of it's lower layers (perhaps as method arguments, or delegate parameters), and if said lower layer uses mango.io rather than phobos.io then a user might become righteously indignant. Sometimes standards are a good thing, regardless of whatever faults they may have. One way to fix such faults is to change the standard, but doing so in a democratic manner is no easy task <g>
>
> While moving mango.io to Deimos is certainly possible, it wouldn't be my first choice. My first choice would be that mango.io is moved to *PHOBOS*. D absolutely requires a serious and well thought out streams package AS STANDARD.
>
> Now, Deimos is kind of a testing ground for Phobos-wannabes. I don't imagine there's anything in Deimos/etc that wouldn't rather be in Phobos/std, but obviously we accept that things have to be "out there in the field" for a
while,
> getting a good testing, getting all the bugs fixed, and so on. You wouldn't
want
> something in Phobos unless it had passed that test. But the thing about
mango.io
> is - it has ALREADY passed that test. It has been out there, in the field, for some time now; all the major bugs have been found and fixed; no-one is planning any reorganization of mango.io in the near future; the class and function names are not going to change. In short, it is stable.
>
> What can I say? It's a question of power. Only Walter (so far as I know) has
the
> power to move things to Phobos, but anyone can move things to Deimos.
>
> But maybe it's also a question of organization. Maybe mango.io could divorce itself from the rest of Mango and move to Deimos for now (in which case everything else in Deimos will be able to call it without worrying about requiring additional libraries, which would certainly be great). But Deimos itself is nothing special - it's just another library, and there are plenty of them around. True, it's a library full of things that would rather be in
Phobos,
> but Mango already has credibility in its own right. On the other hand, I'd be reluntant to download/import/link against a whole server package, if all I wanted to do was to open a file.
>
> Let's be honest here - there are SERIOUS problems with std.stream. It is absurd
> that calling new File(filename, FileMode.Out) will not delete (truncate) an old
> file of the same name. It is absurd that, if you want to do this, you require
> two statements: f = new File(); f.create(...);. It is absurd that if you want
to
> wrap this in a BufferedStream, you have to call create() /before/ you construct
> the buffered stream (because BufferedStream has no create() function). And it
is
> pretty damn annoying that if you continually read from a BufferedStream which buffers a File, using the readLine() function, then there appears to be no way to distinguish between an empty line and end-of-file (they both return null,
and
> no exceptions are thrown). Why is there no Stream.eof() function? Please -
let's
> just replace it with something that JUST WORKS (and is actually documented).
>
> So, personally, I think Walter should simply make us all happy by adding mango.io to Phobos (possibly renaming it to std.io en route) and deprecating std.stream. Failing that, moving mango.io to Deimos (etc.io ?) would be my second choice.
>
> Arcane Jill
>
>

If you want my opinion (which you probably don't) then I pitch that the I/O for console and file operate like C++. With the exception of replacing the >> and << with ~ and damn the person who can't tell whether he is getting input or output. I believe that all the >> and << are doing is placing the stuff in a buffer anyway.

You could use modifiers like what C++ uses for formatting and it would be nice to have Perl Formatting. This perl formatting:
.	format $header =
.<<<<<<<<	<<<<<<<<	<<<<<<<
.$first, $second, $third
'.'

or something, it has been a while since I have done Perl but the general  idea is there. Since one of the problems with Perl's Formatting is that you have to init the variables before you use them. I pitch also that something like this is done:

.	classname ~ "<<<<<<<<" ~ "||||" ~ ">>>>>>>>>>>>>";

to set the up the formatting parameters and then for placing variables into the format:

.	classname ~ variable1 ~ variable2 ~ module::next ~ variable3 ~ variable4

If modifier 'next' is called then place the variables before it (if not before another 'next') into the same position else place each into a separate position. It would be better than having 'next' after all positions. The class should be smart enough to know what is happening. Or "Do What I Want" paradigm. I'm sure someone could think of a better way but here is my pitch: bow to or curse it.

> Kris wrote:
> In general, how would people like to see formatted IO operate? What about
> Ben's idea? How should the upcoming unicode library operate within formatted
> IO? Or should it?

"Matthew" wrote ...
> My opinion is that neither should be in the 1.0 standard library, so we
have
> freedom to have a proper competitive, tested, comprehensive implementation
for
> 2.0, which will be maximally efficient, usable, comprehensible and robust.

I couldn't agree more Matthew. However, the fact that std.stream is already in phobos gives it a decided advantage. That means the playing field is, unfortunately, not as you idealize it above. Nor will it be regarding DTL, since you already have a percieved advantage via your connection with Walter (obviated by the digitalmars.D.dtl NG). Don't get me wrong ~ there's no sour grapes here. Just making a point that reality is rarely unbiased. Let's not give anyone the wrong impression.

> C++ streams library only manages 1.5 / 4 there, and that took a long time
to
> develop.

<black humour>
As you say; the C++ streams library did indeed take a long time to develop.
How long does it usually take to admit that a fundamental approach is
tragically flawed? (sorry; sorry ... just a bad joke)
</black humour>

> It may be that Mango ends up being the standard streams for Phobos, or std.stream, or a refactored of std.stream, or something entirely new.

*mango.io* is but one small independent branch of the Mango Tree, Matthew <g> Perhaps we ought to rename it yet again. Also, as noted elsewhere, mango.io and std.stream are comparable on a superficial basis only. Although they both clearly perform IO of some kind, that's perhaps the extent of their relationship. Where the Phobos library has many vaguely related, and somewhat fractured modules related to IO, mango.io tries hard to be fairly cohesive. Perhaps that is the primary reason why those who use it like it as much as they do? I hope you'll like it too, when you start disseminating the mango.servlet package :-)

For the record, let me state that I'm not personlly advocating mango.io should be in Phobos. Someone please correct me if I'm wrong, but I've noted only that I wish it to be reviewed (and perhaps ratified) by the oft-discussed but non-existent "D standard library group committee", along with other members of the Mango Tree family (see old NG for details on the "committee"). The last thing I want (or need) is for mango.io and std.stream to become political footballs; that would be entirely unhelpful to the whole D community.

How about that darned DSLG committee? Lars? Walter?

- Kris


> Since std.stream is in there, I don't expect it to be taken out. But I do
think
> that the above open-mindedness should be manifest in the community, and
clearly
> expressed to all users, especially new ones.
>
> D has the faculties to mean that we have the potential to have the best IO libraries in the C-family world. I hope it will be realised.
>
>
>
> "Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cbc1t0$6h7$1@digitaldaemon.com...
> > In article <cbaj13$10pl$1@digitaldaemon.com>, Kris says...
> > >
> > >Mango.io could indeed be placed into Demios without issue, if you folks
feel
> > >that's the right home for it. However, the point about mixing portions
of
> > >libraries is a good one: sometimes a library must expose some of it's
lower
> > >layers (perhaps as method arguments, or delegate parameters), and if
said
> > >lower layer uses mango.io rather than phobos.io then a user might
become
> > >righteously indignant. Sometimes standards are a good thing, regardless
of
> > >whatever faults they may have. One way to fix such faults is to change
the
> > >standard, but doing so in a democratic manner is no easy task <g>
> >
> > While moving mango.io to Deimos is certainly possible, it wouldn't be my
first
> > choice. My first choice would be that mango.io is moved to *PHOBOS*. D absolutely requires a serious and well thought out streams package AS
STANDARD.
> >
> > Now, Deimos is kind of a testing ground for Phobos-wannabes. I don't
imagine
> > there's anything in Deimos/etc that wouldn't rather be in Phobos/std,
but
> > obviously we accept that things have to be "out there in the field" for
a
> while,
> > getting a good testing, getting all the bugs fixed, and so on. You
wouldn't
> want
> > something in Phobos unless it had passed that test. But the thing about
> mango.io
> > is - it has ALREADY passed that test. It has been out there, in the
field, for
> > some time now; all the major bugs have been found and fixed; no-one is
planning
> > any reorganization of mango.io in the near future; the class and
function names
> > are not going to change. In short, it is stable.
> >
> > What can I say? It's a question of power. Only Walter (so far as I know)
has
> the
> > power to move things to Phobos, but anyone can move things to Deimos.
> >
> > But maybe it's also a question of organization. Maybe mango.io could
divorce
> > itself from the rest of Mango and move to Deimos for now (in which case everything else in Deimos will be able to call it without worrying about requiring additional libraries, which would certainly be great). But
Deimos
> > itself is nothing special - it's just another library, and there are
plenty of
> > them around. True, it's a library full of things that would rather be in
> Phobos,
> > but Mango already has credibility in its own right. On the other hand,
I'd be
> > reluntant to download/import/link against a whole server package, if all
I
> > wanted to do was to open a file.
> >
> > Let's be honest here - there are SERIOUS problems with std.stream. It is
absurd
> > that calling new File(filename, FileMode.Out) will not delete (truncate)
an old
> > file of the same name. It is absurd that, if you want to do this, you
require
> > two statements: f = new File(); f.create(...);. It is absurd that if you
want
> to
> > wrap this in a BufferedStream, you have to call create() /before/ you
construct
> > the buffered stream (because BufferedStream has no create() function).
And it
> is
> > pretty damn annoying that if you continually read from a BufferedStream
which
> > buffers a File, using the readLine() function, then there appears to be
no way
> > to distinguish between an empty line and end-of-file (they both return
null,
> and
> > no exceptions are thrown). Why is there no Stream.eof() function?
Please -
> let's
> > just replace it with something that JUST WORKS (and is actually
documented).
> >
> > So, personally, I think Walter should simply make us all happy by adding mango.io to Phobos (possibly renaming it to std.io en route) and
deprecating
> > std.stream. Failing that, moving mango.io to Deimos (etc.io ?) would be
my
> > second choice.
> >
> > Arcane Jill
> >
> >
>
>

In article <cbcgcj$u8q$1@digitaldaemon.com>, Kris says...
>
>"Sean Kelly" wrote
> Numeric formatting is pretty easy, but that still
>leaves
> character transcoding, doesn't it?

I don't understand. What's character transcoding?


>I wholeheartedly agree. Didn't Ben post something about Perl formatting? I think the combination of what Ben mentioned together with char transcoding would be a great thing for any IO package.

It's obviously important then. What is it?


>Note that mango.io is also completely deficient regarding unicode. There were too many unknowns at the time of writing, so it was left out until a more formal approach could be introduced. Thanks to Hauke and AJ, the latter appears to be happening (and mango.io will probably integrate their work as an additional flavour of Reader & Writer).
>
>In general, how would people like to see formatted IO operate? What about Ben's idea? How should the upcoming unicode library operate within formatted IO? Or should it?

Well, just to clarify what's "upcoming" on the Unicode front:

In the next few days, functions to access all Unicode character properties. This is an important first step, because the Unicode algorithms are defined in terms of those properties.

Sometime after that, normalization algorithms. This is slightly complicated in that, for completeness, we'd want it continue to work in the event of PUA (Private Use Area) customization.

I was planning on stopping after that for a short break and going back to crypto (finish off the hash section). Presumably next on the list for Unicode should come the full casing algorithms - these are actually locale-sensitive (though only rarely, since all locales give identical results apart from "az", "lt" and "tr").

Simply put, the improvement you will see will be gradual. We started with functions like std.ctype.toupper(), defined only for ASCII characters; Hauke gave us utype.toupper() and friends, which extended that to all characters. Before long, we'll have a string toupper-ing function that does full casing.

I'm not completely sure I understand the question "how would people like to see formatted IO operate?", or what it has to do with Unicode. Now, there are some really big and powerful algorithms described out there on the Unicode web site, and one of them concerns Unicode Regular Expressions - a staggeringly powerful concept - but probably the most difficult of all Unicode algorithms to implement in practice. You'll probably want that one, but alas I fear it will be one of the last to arrive.

Anyway, if I'm way off track, forgive me.

Much of localization has to do with replacing text strings (normally English) with a translation into some alternative language. This is usually done at the pre-stream level (in my experience), so by the time it gets to the stream, it's already in French/German/whatever.

But there's obviously something I'm not getting here. Ah well. Put it down to my not being as bright as I'd like to be.

Jill

> "Matthew" wrote ...
> > My opinion is that neither should be in the 1.0 standard library, so we
> have
> > freedom to have a proper competitive, tested, comprehensive implementation
> for
> > 2.0, which will be maximally efficient, usable, comprehensible and robust.
>
> I couldn't agree more Matthew. However, the fact that std.stream is already in phobos gives it a decided advantage. That means the playing field is, unfortunately, not as you idealize it above.

True. But if std.stream does not cut the mustard, I for one will be voicing for change.

I think streaming, and especially object instance serialisation/marshalling/streaming/pickling/whatever-you-want-to-call-it, will be a feature that D *must* do right, in order to curtail comparisons with Java, Python and other languages that do this well on at least one of the four criteria on which I've scored C++ 1.5.

I totally agree with Walter that this is something that 1.0 can't wait for. It's also something that will require a very large amount of design, development and refinement, including large amounts of Walter's time - as it'll probably have to involve language as well as library - and lots of input from people with different backgrounds, to get it 100% correct correct. (Well, 95%; there are no 100s.)

> Nor will it be regarding DTL,
> since you already have a percieved advantage via your connection with Walter

Maybe there's an advantage there. But any "connection" with Walter stems from being enthusiastic, and putting as much effort into writing code as into writing NG posts. It's not really anything more than that. (Of course, maybe when our book's more corporeal than corporate schpiel we'll have an irrevocable connection. Pity Walter from that point on. <g>)

Regarding DTL. I have had what I think is a good idea, and Walter has agreed thus far. But a combination of compiler bugs (which I've yet to distill) and an all-consuming workload has meant that nothing's really happened from the initial implementation in March. I intend and expect to rectify that by the end of July. But there's a big gap in time. If someone else had a grand idea for DTL then they've had plenty of time to develop/refine it. I've said all along that DTL-MW is not a done deal, and that others should persue alternatives if they have them, and we can evaluate *all* options on their merits.

> (obviated by the digitalmars.D.dtl NG).

<pedantic>"obviated"? I think you mean "exemplified". Obviate means to render unnecessary</pedantic>

> Don't get me wrong ~ there's no sour
> grapes here.

Kris. You don't need to say that. I know you know that you have my undying respect ...

> Just making a point that reality is rarely unbiased. Let's not give anyone the wrong impression.

Again. Yes and no. Despite the occasional heat, I think just about everyone here is more interested in D being really good, than in just getting their own opinions swallowed. (At least I hope so!) So I think right will out in most cases, especially the big ones.

> > C++ streams library only manages 1.5 / 4 there, and that took a long time
> to
> > develop.
>
> <black humour>
> As you say; the C++ streams library did indeed take a long time to develop.
> How long does it usually take to admit that a fundamental approach is
> tragically flawed? (sorry; sorry ... just a bad joke)
> </black humour>

Well, Java's been with us for nearly a decade ...

To be serious, for all that I really don't care for the IOStreams, they do have the localisation issue relatively well handled. That's not something to sniff at, even though it does have high performance costs.

> > It may be that Mango ends up being the standard streams for Phobos, or std.stream, or a refactored of std.stream, or something entirely new.
>
> *mango.io* is but one small independent branch of the Mango Tree, Matthew <g> Perhaps we ought to rename it yet again. Also, as noted elsewhere, mango.io and std.stream are comparable on a superficial basis only. Although they both clearly perform IO of some kind, that's perhaps the extent of their relationship. Where the Phobos library has many vaguely related, and somewhat fractured modules related to IO, mango.io tries hard to be fairly cohesive. Perhaps that is the primary reason why those who use it like it as much as they do?

I know, I know. Apologies for my abuse: loose use of language. I'm a goose. I'll try and spruce it up, be less abstruse.

> I hope you'll like it too, when you start disseminating the mango.servlet package :-)

Yes. I've promised to do that July, and I'll keep it.

> For the record, let me state that I'm not personlly advocating mango.io should be in Phobos. Someone please correct me if I'm wrong, but I've noted only that I wish it to be reviewed (and perhaps ratified) by the oft-discussed but non-existent "D standard library group committee", along with other members of the Mango Tree family (see old NG for details on the "committee"). The last thing I want (or need) is for mango.io and std.stream to become political footballs; that would be entirely unhelpful to the whole D community.

Nope. AFAICR, you've not said that.

In any case, playing football with a mango would be a huge waste. Mangos must be respectfully, even reverently, consumed.


> How about that darned DSLG committee? Lars? Walter?
>
> - Kris
>
>
> > Since std.stream is in there, I don't expect it to be taken out. But I do
> think
> > that the above open-mindedness should be manifest in the community, and
> clearly
> > expressed to all users, especially new ones.
> >
> > D has the faculties to mean that we have the potential to have the best IO libraries in the C-family world. I hope it will be realised.
> >
> >
> >
> > "Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cbc1t0$6h7$1@digitaldaemon.com...
> > > In article <cbaj13$10pl$1@digitaldaemon.com>, Kris says...
> > > >
> > > >Mango.io could indeed be placed into Demios without issue, if you folks
> feel
> > > >that's the right home for it. However, the point about mixing portions
> of
> > > >libraries is a good one: sometimes a library must expose some of it's
> lower
> > > >layers (perhaps as method arguments, or delegate parameters), and if
> said
> > > >lower layer uses mango.io rather than phobos.io then a user might
> become
> > > >righteously indignant. Sometimes standards are a good thing, regardless
> of
> > > >whatever faults they may have. One way to fix such faults is to change
> the
> > > >standard, but doing so in a democratic manner is no easy task <g>
> > >
> > > While moving mango.io to Deimos is certainly possible, it wouldn't be my
> first
> > > choice. My first choice would be that mango.io is moved to *PHOBOS*. D absolutely requires a serious and well thought out streams package AS
> STANDARD.
> > >
> > > Now, Deimos is kind of a testing ground for Phobos-wannabes. I don't
> imagine
> > > there's anything in Deimos/etc that wouldn't rather be in Phobos/std,
> but
> > > obviously we accept that things have to be "out there in the field" for
> a
> > while,
> > > getting a good testing, getting all the bugs fixed, and so on. You
> wouldn't
> > want
> > > something in Phobos unless it had passed that test. But the thing about
> > mango.io
> > > is - it has ALREADY passed that test. It has been out there, in the
> field, for
> > > some time now; all the major bugs have been found and fixed; no-one is
> planning
> > > any reorganization of mango.io in the near future; the class and
> function names
> > > are not going to change. In short, it is stable.
> > >
> > > What can I say? It's a question of power. Only Walter (so far as I know)
> has
> > the
> > > power to move things to Phobos, but anyone can move things to Deimos.
> > >
> > > But maybe it's also a question of organization. Maybe mango.io could
> divorce
> > > itself from the rest of Mango and move to Deimos for now (in which case everything else in Deimos will be able to call it without worrying about requiring additional libraries, which would certainly be great). But
> Deimos
> > > itself is nothing special - it's just another library, and there are
> plenty of
> > > them around. True, it's a library full of things that would rather be in
> > Phobos,
> > > but Mango already has credibility in its own right. On the other hand,
> I'd be
> > > reluntant to download/import/link against a whole server package, if all
> I
> > > wanted to do was to open a file.
> > >
> > > Let's be honest here - there are SERIOUS problems with std.stream. It is
> absurd
> > > that calling new File(filename, FileMode.Out) will not delete (truncate)
> an old
> > > file of the same name. It is absurd that, if you want to do this, you
> require
> > > two statements: f = new File(); f.create(...);. It is absurd that if you
> want
> > to
> > > wrap this in a BufferedStream, you have to call create() /before/ you
> construct
> > > the buffered stream (because BufferedStream has no create() function).
> And it
> > is
> > > pretty damn annoying that if you continually read from a BufferedStream
> which
> > > buffers a File, using the readLine() function, then there appears to be
> no way
> > > to distinguish between an empty line and end-of-file (they both return
> null,
> > and
> > > no exceptions are thrown). Why is there no Stream.eof() function?
> Please -
> > let's
> > > just replace it with something that JUST WORKS (and is actually
> documented).
> > >
> > > So, personally, I think Walter should simply make us all happy by adding mango.io to Phobos (possibly renaming it to std.io en route) and
> deprecating
> > > std.stream. Failing that, moving mango.io to Deimos (etc.io ?) would be
> my
> > > second choice.
> > >
> > > Arcane Jill
> > >
> > >
> >
> >
>
>

In article <cbd3p3$1tef$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <cbcgcj$u8q$1@digitaldaemon.com>, Kris says...
>>
>>"Sean Kelly" wrote
>> Numeric formatting is pretty easy, but that still
>>leaves character transcoding, doesn't it?
>
>I don't understand. What's character transcoding?

Say I has a string of dchars and I want to write it to a text file.  Is it enough to just do an unformatted write of the string or does it have to be converted to UTF-16 or some such?  ie. is there ever any difference between internal character representation and external representation that an i/o lib may care about?

>I'm not completely sure I understand the question "how would people like to see formatted IO operate?", or what it has to do with Unicode.

What I meant was any internationalization.  As I mentioned, the issues I know of have to do with numeric formatting, but is there anything else?

Sean

Just thought of another one.  What constitutes whitespace is locale dependent as well.  So add that to the localization list.

"Matthew" wrote
> I think streaming, and especially object instance serialisation/marshalling/streaming/pickling/whatever-you-want-to-call-it, will be a feature that D *must* do right, in order to curtail comparisons with Java, Python and other languages that do this well on at least one of the four criteria on which I've scored C++ 1.5

Ah, pickling! There's been so many times we've worked around the predefined Java serialization that I've had team members use an alternative. Especially after tracing just how inefficient it is; not to mention arcane. The Serializable interface is cool, but the hidden methods (private yet somehow public) to intercept default processing are, uhhhh, funky. Then they had to extend the language with keywords such as transient ... it's a solution that looks immediately viable, yet soon runs out of steam. But it works, which is the main thing.

It may be naive of me to think that explicitly coding which members of a class are pickled is the better way to go, provided there's an easy, flexible and consistent framework to operate within. But that's where my thoughts lie ~ IMO, v1.0 should absolutely not wait for this to be ground out.

> Maybe there's an advantage there. But any "connection" with Walter stems from being enthusiastic, and putting as much effort into writing code as
into
> writing NG posts. It's not really anything more than that.

If that's all it takes, the myriad projects at dsource.org should be given an equal level of "connection" then! Can they all have sections on the NG too please! <g>

> <pedantic>"obviated"? I think you mean "exemplified". Obviate means to render unnecessary</pedantic>

Yeah; it's a bit annoying when one changes the wording of something, and then can't remedy errors after posting.

> > <black humour>
> > As you say; the C++ streams library did indeed take a long time to
develop.
> > How long does it usually take to admit that a fundamental approach is
> > tragically flawed? (sorry; sorry ... just a bad joke)
> > </black humour>
>
> Well, Java's been with us for nearly a decade ...

Too true. Even Bruce Eckel could barely contain disparaging remarks regarding Java IO in his truly excellent book (TIJ). It just goes to show that such things shouldn't be hurried into a standard library for a v1.0 release (re std.streams); poor Java has paid for it in spades (and hacks) ever since, due to backward compatibility. Even NIO is lumbered.

> To be serious, for all that I really don't care for the IOStreams, they do have the localisation issue relatively well handled. That's not something to sniff at, even though it does have high performance costs.

I think it would be really helpful to expound on this particular note over in that "IO formatting" thread. How about it Matthew? I, for one, would likely learn something anew.

> In any case, playing football with a mango would be a huge waste. Mangos must be respectfully, even reverently, consumed.

How about Australian Rugby then?

Sean Kelly wrote:

> Mango.io has some very nice design features and it may well be a candidate for
> Demios.  I've been trying to get stream.d up to date mostly to have an alternate
> technique available for comparison.  I'm interedted in seeing the pros and cons
> of both methods :)
> 
> Sean
> 
> 

My vote is to get mango.io into Demios.  If anything's lacking, contributors certainly can start brainstorming some improvements from within Demios.  It's an excellent base at the very least.

Come on people, let's decide on this one. :-)

Later,

John

In article <cbdfjg$2e4b$1@digitaldaemon.com>, Kris says...
>
>"Matthew" wrote
>>
>> Well, Java's been with us for nearly a decade ...
>
>Too true. Even Bruce Eckel could barely contain disparaging remarks regarding Java IO in his truly excellent book (TIJ). It just goes to show that such things shouldn't be hurried into a standard library for a v1.0 release (re std.streams); poor Java has paid for it in spades (and hacks) ever since, due to backward compatibility.

And don't forget the Java GUI API, which was changed completely between 1.0 and 2.0.  I think basic i/o is important to have for 1.0, but I'd much rather have the fancy stuff come later than be stuck supporting bad decisions.

Sean