Re: std.xml should just go

2011-02-14 Thread Steven Schveighoffer
On Fri, 11 Feb 2011 19:06:48 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 2/11/11 8:31 AM, Bruno Medeiros wrote: On 04/02/2011 16:14, Eric Poggel wrote: On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote: At this point there is no turning back from ranges, unless we come

Re: std.xml should just go

2011-02-14 Thread spir
On 02/14/2011 04:11 PM, Steven Schveighoffer wrote: On Fri, 11 Feb 2011 19:06:48 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 2/11/11 8:31 AM, Bruno Medeiros wrote: On 04/02/2011 16:14, Eric Poggel wrote: On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote: At this point

Re: std.xml should just go

2011-02-14 Thread retard
Mon, 14 Feb 2011 18:48:53 +0100, spir wrote: On 02/14/2011 04:11 PM, Steven Schveighoffer wrote: On Fri, 11 Feb 2011 19:06:48 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 2/11/11 8:31 AM, Bruno Medeiros wrote: On 04/02/2011 16:14, Eric Poggel wrote: On 2/3/2011 10:20

Re: std.xml should just go

2011-02-12 Thread bearophile
Jonathan M Davis: Except that then you get the issue of eager vs lazy concatenation. chain is lazy whereas ~ is eager, so that wouldn't fly. In dlibs1 I have a lazy chain(). If you perform a chain(chain(x, y), z) or chain(x, chain(y, z)) it's rewritten as chain(x,y,z). Plus there's a

Re: std.xml should just go

2011-02-12 Thread Jonathan M Davis
On Saturday 12 February 2011 03:08:15 bearophile wrote: Jonathan M Davis: Except that then you get the issue of eager vs lazy concatenation. chain is lazy whereas ~ is eager, so that wouldn't fly. In dlibs1 I have a lazy chain(). If you perform a chain(chain(x, y), z) or chain(x, chain(y,

Re: std.xml should just go

2011-02-12 Thread bearophile
Jonathan M Davis: It's a problem of semantics. ~ is intended for eager concatenation. That's how it's designed and what it's expected to mean. This is written nowhere. I am referring to my second proposal. It makes code more generic, because it allows you to use ~ for both arrays and lazy

Re: std.xml should just go

2011-02-12 Thread spir
On 02/12/2011 03:17 PM, bearophile wrote: Jonathan M Davis: It's a problem of semantics. ~ is intended for eager concatenation. That's how it's designed and what it's expected to mean. This is written nowhere. I am referring to my second proposal. It makes code more generic, because it

Re: std.xml should just go

2011-02-12 Thread Jonathan M Davis
On Saturday 12 February 2011 06:26:40 spir wrote: On 02/12/2011 03:17 PM, bearophile wrote: Jonathan M Davis: It's a problem of semantics. ~ is intended for eager concatenation. That's how it's designed and what it's expected to mean. This is written nowhere. I am referring to my

Re: std.xml should just go

2011-02-12 Thread bearophile
spir: what about using '*' for chaining syntax sugar. I mean, func composition is often written using '.' which means product (and is sometimes even spelled product for functions too), right? And product is written '*' in D... What do you think? I think that using * for lazy chaining

Re: std.xml should just go

2011-02-12 Thread so
Walter already decided against using + for concatenation because of the perceived ambiguity - e.g. does 5 + 2 do 52 or 7? He's not going to go for * for anything similar. Honestly, we don't need more syntactic sugar at this point. - Jonathan M Davis Isn't it quite obvious? Both + * serves

Re: std.xml should just go

2011-02-11 Thread Bruno Medeiros
On 04/02/2011 21:07, Steven Schveighoffer wrote: On Fri, 04 Feb 2011 15:44:46 -0500, Jeff Nowakowski j...@dilacero.org wrote: On 02/03/2011 10:07 PM, Walter Bright wrote: The way to get a high performance string parser in D is to take advantage of one of D's unique features - slices. Java,

Re: std.xml should just go

2011-02-11 Thread Bruno Medeiros
On 06/02/2011 21:30, Jacob Carlborg wrote: On 2011-02-06 20:59, Walter Bright wrote: Jacob Carlborg wrote: On 2011-02-04 20:33, Walter Bright wrote: so wrote: It doesn't matter what signature you use for the function, compiler is aware and will output an error when you do the opposite of the

Re: std.xml should just go

2011-02-11 Thread Steven Schveighoffer
On Fri, 11 Feb 2011 08:19:51 -0500, Bruno Medeiros brunodomedeiros+spam@com.gmail wrote: On 04/02/2011 21:07, Steven Schveighoffer wrote: On Fri, 04 Feb 2011 15:44:46 -0500, Jeff Nowakowski j...@dilacero.org wrote: On 02/03/2011 10:07 PM, Walter Bright wrote: The way to get a high

Re: std.xml should just go

2011-02-11 Thread Bruno Medeiros
On 11/02/2011 13:48, Steven Schveighoffer wrote: On Fri, 11 Feb 2011 08:19:51 -0500, Bruno Medeiros brunodomedeiros+spam@com.gmail wrote: On 04/02/2011 21:07, Steven Schveighoffer wrote: On Fri, 04 Feb 2011 15:44:46 -0500, Jeff Nowakowski j...@dilacero.org wrote: On 02/03/2011 10:07 PM,

Re: std.xml should just go

2011-02-11 Thread Bruno Medeiros
On 04/02/2011 16:14, Eric Poggel wrote: On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote: At this point there is no turning back from ranges, unless we come about with an even better idea (I discussed one with Walter but we're not pursuing it yet). Care to elaborate on the new idea? Or at

Re: std.xml should just go

2011-02-11 Thread Michel Fortin
On 2011-02-11 09:29:03 -0500, Bruno Medeiros brunodomedeiros+spam@com.gmail said: On 11/02/2011 13:48, Steven Schveighoffer wrote: I think D can do it without copying out of the buffer. You just have to avoid using immutable strings. -Steve The data that you want to keep afterwards you

Re: std.xml should just go

2011-02-11 Thread Andrei Alexandrescu
On 2/11/11 8:31 AM, Bruno Medeiros wrote: On 04/02/2011 16:14, Eric Poggel wrote: On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote: At this point there is no turning back from ranges, unless we come about with an even better idea (I discussed one with Walter but we're not pursuing it yet).

Re: std.xml should just go

2011-02-11 Thread bearophile
Andrei: Now we have a unified way of referring to elements in ranges. Walter's excellent follow-up is that the compiler could use lowering such that you don't even need to use first and last. You'd just use r[0] and r[$ - 1] and the compiler would take care of handling these special cases.

Re: std.xml should just go

2011-02-11 Thread Jonathan M Davis
On Friday, February 11, 2011 17:01:31 bearophile wrote: Andrei: Now we have a unified way of referring to elements in ranges. Walter's excellent follow-up is that the compiler could use lowering such that you don't even need to use first and last. You'd just use r[0] and r[$ - 1] and the

Re: std.xml should just go

2011-02-07 Thread BLS
On 06/02/2011 16:41, Andrei Alexandrescu wrote: On 2/5/11 17:54 EST, BLS wrote: On 04/02/2011 04:20, Andrei Alexandrescu wrote: Cool. Is Michael Rynn willing to make a submission? He announced a while ago in d.announce. std.xml2 candidate.. A few weeks earlier (if am not completely wrong) he

Re: std.xml should just go

2011-02-07 Thread Andrei Alexandrescu
On 2/7/11 12:02 PM, BLS wrote: On 06/02/2011 16:41, Andrei Alexandrescu wrote: On 2/5/11 17:54 EST, BLS wrote: On 04/02/2011 04:20, Andrei Alexandrescu wrote: Cool. Is Michael Rynn willing to make a submission? He announced a while ago in d.announce. std.xml2 candidate.. A few weeks earlier

Re: std.xml should just go

2011-02-06 Thread Jacob Carlborg
On 2011-02-04 20:33, Walter Bright wrote: so wrote: It doesn't matter what signature you use for the function, compiler is aware and will output an error when you do the opposite of the signature. If this is the case, why do we need that signature? Examine the API of a function in a library.

Re: std.xml should just go

2011-02-06 Thread Jacob Carlborg
On 2011-02-04 21:44, Jeff Nowakowski wrote: On 02/03/2011 10:07 PM, Walter Bright wrote: The way to get a high performance string parser in D is to take advantage of one of D's unique features - slices. Java, C++, C#, etc., all rely on copying strings. With D you can just use slices into the

Re: std.xml should just go

2011-02-06 Thread Andrei Alexandrescu
On 2/5/11 17:54 EST, BLS wrote: On 04/02/2011 04:20, Andrei Alexandrescu wrote: Cool. Is Michael Rynn willing to make a submission? He announced a while ago in d.announce. std.xml2 candidate.. A few weeks earlier (if am not completely wrong) he offers his implementation for phobos. We need

Re: std.xml should just go

2011-02-06 Thread Jeff Nowakowski
On 02/06/2011 05:43 AM, Jacob Carlborg wrote: On 2011-02-04 21:44, Jeff Nowakowski wrote: Java's substring() does not copy the text, at least in the official JDK implementation. Unfortunately, it doesn't specify this behavior as part of the String API. But, I assume, it will allocate a new

Re: std.xml should just go

2011-02-06 Thread Walter Bright
Jacob Carlborg wrote: On 2011-02-04 08:34, Jonathan M Davis wrote: Slices: just one more reason why D's arrays kick the pants of other languages' arrays... - Jonathan M Davis Ruby has array slices as well. A slice of an array refers to the original data just like in D. But on the other

Re: std.xml should just go

2011-02-06 Thread Walter Bright
Jacob Carlborg wrote: On 2011-02-04 20:33, Walter Bright wrote: so wrote: It doesn't matter what signature you use for the function, compiler is aware and will output an error when you do the opposite of the signature. If this is the case, why do we need that signature? Examine the API of a

Re: std.xml should just go

2011-02-06 Thread Walter Bright
Jeff Nowakowski wrote: On 02/06/2011 05:43 AM, Jacob Carlborg wrote: On 2011-02-04 21:44, Jeff Nowakowski wrote: Java's substring() does not copy the text, at least in the official JDK implementation. Unfortunately, it doesn't specify this behavior as part of the String API. But, I assume,

Re: std.xml should just go

2011-02-06 Thread bearophile
Walter: Can you use an array slice in ruby as an argument to any function that takes a string? The NumPy library for Python uses light slices, that are seen as normal NumPy arrays, like in D. NumPy arrays may contain numbers, chars, records, etc. Bye, bearophile

Re: std.xml should just go

2011-02-06 Thread Jacob Carlborg
On 2011-02-06 20:51, Walter Bright wrote: Jacob Carlborg wrote: On 2011-02-04 08:34, Jonathan M Davis wrote: Slices: just one more reason why D's arrays kick the pants of other languages' arrays... - Jonathan M Davis Ruby has array slices as well. A slice of an array refers to the original

Re: std.xml should just go

2011-02-06 Thread Jacob Carlborg
On 2011-02-06 20:59, Walter Bright wrote: Jacob Carlborg wrote: On 2011-02-04 20:33, Walter Bright wrote: so wrote: It doesn't matter what signature you use for the function, compiler is aware and will output an error when you do the opposite of the signature. If this is the case, why do we

Re: std.xml should just go

2011-02-06 Thread spir
On 02/06/2011 10:28 PM, Jacob Carlborg wrote: On 2011-02-06 20:51, Walter Bright wrote: Jacob Carlborg wrote: On 2011-02-04 08:34, Jonathan M Davis wrote: Slices: just one more reason why D's arrays kick the pants of other languages' arrays... - Jonathan M Davis Ruby has array slices as

Re: std.xml should just go

2011-02-05 Thread Lutger Blijdestijn
Andrej Mitrovic wrote: On 2/4/11, spir denis.s...@gmail.com wrote: About that, I would love a tutorial about eponymous templates starting with their /purpose/ (why does this feature even exist? what does it /mean/? what does it compare/oppose to? why is one supposed to need/enjoy it? how is

Re: std.xml should just go

2011-02-05 Thread so
The case is different --I mean the comparison does not hold IIUC. Virtual methods are /intended/ to be overriden, this is precisely part of their semantics. While the whole point of const-the-D-way is to ensure actual constness as marked in a given function's signature, whatever this

Re: std.xml should just go

2011-02-05 Thread Jacob Carlborg
On 2011-02-04 08:34, Jonathan M Davis wrote: Slices: just one more reason why D's arrays kick the pants of other languages' arrays... - Jonathan M Davis Ruby has array slices as well. A slice of an array refers to the original data just like in D. But on the other hand a new instance is

Re: std.xml should just go

2011-02-05 Thread BLS
On 04/02/2011 04:20, Andrei Alexandrescu wrote: Cool. Is Michael Rynn willing to make a submission? He announced a while ago in d.announce. std.xml2 candidate.. A few weeks earlier (if am not completely wrong) he offers his implementation for phobos. Regarding ranges. - Ranges of ranges

Re: std.xml should just go

2011-02-04 Thread Don
Andrei Alexandrescu wrote: On 2/3/11 7:56 PM, BLS wrote: I got more and more the feeling that the D2 monster was made just for ranges. The smart and elegant D1 design is definitely dead an gone. I think I am not the only one who would prefer a D1 plus instead of D2. bjoern All in all it's

Re: std.xml should just go

2011-02-04 Thread Walter Bright
Max Samukha wrote: .NET and Qt do have slices of some kind: http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx http://doc.qt.nokia.com/latest/qstringref.html#details I am not sure whether their XML libraries use those. .net's slices are inadequate, because its strings are not

Re: std.xml should just go

2011-02-04 Thread Andrei Alexandrescu
On 2/4/11 3:15 AM, Don wrote: Andrei Alexandrescu wrote: On 2/3/11 7:56 PM, BLS wrote: I got more and more the feeling that the D2 monster was made just for ranges. The smart and elegant D1 design is definitely dead an gone. I think I am not the only one who would prefer a D1 plus instead of

Re: std.xml should just go

2011-02-04 Thread Max Samukha
On 02/04/2011 11:24 AM, Walter Bright wrote: Max Samukha wrote: .NET and Qt do have slices of some kind: http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx http://doc.qt.nokia.com/latest/qstringref.html#details I am not sure whether their XML libraries use those. .net's slices are

Re: std.xml should just go

2011-02-04 Thread spir
On 02/04/2011 08:34 AM, Jonathan M Davis wrote: Slices: just one more reason why D's arrays kick the pants of other languages' arrays... What are the other ones? Denis -- _ vita es estrany spir.wikidot.com

Re: std.xml should just go

2011-02-04 Thread spir
On 02/04/2011 10:15 AM, Don wrote: Andrei Alexandrescu wrote: On 2/3/11 7:56 PM, BLS wrote: I got more and more the feeling that the D2 monster was made just for ranges. The smart and elegant D1 design is definitely dead an gone. I think I am not the only one who would prefer a D1 plus

Re: std.xml should just go

2011-02-04 Thread spir
On 02/04/2011 10:32 AM, Andrei Alexandrescu wrote: relaxing the rules for eponymous templates About that, I would love a tutorial about eponymous templates starting with their /purpose/ (why does this feature even exist? what does it /mean/? what does it compare/oppose to? why is one

Re: std.xml should just go

2011-02-04 Thread Kagamin
Max Samukha Wrote: .NET and Qt do have slices of some kind: http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx http://doc.qt.nokia.com/latest/qstringref.html#details I am not sure whether their XML libraries use those. C# uses old good String.

Re: std.xml should just go

2011-02-04 Thread Eric Poggel
On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote: At this point there is no turning back from ranges, unless we come about with an even better idea (I discussed one with Walter but we're not pursuing it yet). Care to elaborate on the new idea? Or at least a quick summary so we're not all left

Re: std.xml should just go

2011-02-04 Thread Andrej Mitrovic
On 2/4/11, spir denis.s...@gmail.com wrote: About that, I would love a tutorial about eponymous templates starting with their /purpose/ (why does this feature even exist? what does it /mean/? what does it compare/oppose to? why is one supposed to need/enjoy it? how is it supposed to help

Re: std.xml should just go

2011-02-04 Thread Walter Bright
spir wrote: On 02/04/2011 08:34 AM, Jonathan M Davis wrote: Slices: just one more reason why D's arrays kick the pants of other languages' arrays... What are the other ones? Scope guard is another. I would argue that transitive const is, too, but the benefits of that are harder to see.

Re: std.xml should just go

2011-02-04 Thread Andrej Mitrovic
Scope guard is another. Scope guard is awesome with C libs that have complicated acquire/release rules. Saves my butt. :D

Re: std.xml should just go

2011-02-04 Thread Walter Bright
BLS wrote: I got more and more the feeling that the D2 monster was made just for ranges. The only range support that is actually in the language is in foreach. That can be ignored if you prefer. Unix's core structure is that everything is a file. Operations are strung together as

Re: std.xml should just go

2011-02-04 Thread so
On Fri, 04 Feb 2011 19:33:09 +0200, Walter Bright newshou...@digitalmars.com wrote: spir wrote: On 02/04/2011 08:34 AM, Jonathan M Davis wrote: Slices: just one more reason why D's arrays kick the pants of other languages' arrays... What are the other ones? Scope guard is another. I

Re: std.xml should just go

2011-02-04 Thread so
This hole is not that explicit in C++ because it is not transitive. Ignore this line... Btw, if i made myself clear to at least one person, please let me know since this is (at least to me) very important.

Re: std.xml should just go

2011-02-04 Thread Walter Bright
so wrote: It doesn't matter what signature you use for the function, compiler is aware and will output an error when you do the opposite of the signature. If this is the case, why do we need that signature? Examine the API of a function in a library. It says it doesn't modify anything

Re: std.xml should just go

2011-02-04 Thread Walter Bright
Andrej Mitrovic wrote: Having a perspective on how all features tie together is crucial to understanding the purpose of individual features themselves. In my opinion! Of course, but both are necessary.

Re: std.xml should just go

2011-02-04 Thread Jesse Phillips
so Wrote: It doesn't matter what signature you use for the function, compiler is aware and will output an error when you do the opposite of the signature. If this is the case, why do we need that signature? Its presence just makes things complicated and with actually no reason. Are you

Re: std.xml should just go

2011-02-04 Thread Andrej Mitrovic
On 2/4/11, Walter Bright newshou...@digitalmars.com wrote: Andrej Mitrovic wrote: Having a perspective on how all features tie together is crucial to understanding the purpose of individual features themselves. In my opinion! Of course, but both are necessary. Well, I'm saying that you've

Re: std.xml should just go

2011-02-04 Thread Steven Schveighoffer
On Fri, 04 Feb 2011 13:49:42 -0500, so s...@so.do wrote: Now, what i mean with this: --- struct A { B whatever; bool opEquals(A a) { return whatever == a.whatever; // just comparision, this function is const } bool anything(A a) { whatever

Re: std.xml should just go

2011-02-04 Thread so
Actually, there are two reasons. First, it's due to the compilation model of D. Without the signature to convey the information, the compiler cannot make any guarantees. It is legal to declare simply a function signature without the relevant source, in order to link against the function.

Re: std.xml should just go

2011-02-04 Thread Walter Bright
so wrote: You changed the function and the new function is not working, just what you expect. It is not silently is it? Unlike you use A a instead of const A a. this const alone would give you all the guaranties you need. What would you do in the case of pointers to functions, virtual

Re: std.xml should just go

2011-02-04 Thread so
Examine the API of a function in a library. It says it doesn't modify anything reachable through its arguments, but is that true? How would you know? And how would you know if the API doc doesn't say? You are right, but try to look at this from another angle (probably i am not making any

Re: std.xml should just go

2011-02-04 Thread Jeff Nowakowski
On 02/03/2011 10:07 PM, Walter Bright wrote: The way to get a high performance string parser in D is to take advantage of one of D's unique features - slices. Java, C++, C#, etc., all rely on copying strings. With D you can just use slices into the original XML source text. If you're copying

Re: std.xml should just go

2011-02-04 Thread Walter Bright
so wrote: Examine the API of a function in a library. It says it doesn't modify anything reachable through its arguments, but is that true? How would you know? And how would you know if the API doc doesn't say? You are right, but try to look at this from another angle (probably i am not

Re: std.xml should just go

2011-02-04 Thread so
What would you do in the case of pointers to functions, virtual functions, functions implemented with inline assembly, and functions for which the source is not available? Just like we don't know if the derived class overrides a given function, we could do something similar i suppose?

Re: std.xml should just go

2011-02-04 Thread Steven Schveighoffer
On Fri, 04 Feb 2011 15:26:07 -0500, so s...@so.do wrote: Actually, there are two reasons. First, it's due to the compilation model of D. Without the signature to convey the information, the compiler cannot make any guarantees. It is legal to declare simply a function signature without

Re: std.xml should just go

2011-02-04 Thread so
On Fri, 04 Feb 2011 22:44:51 +0200, Walter Bright newshou...@digitalmars.com wrote: so wrote: Examine the API of a function in a library. It says it doesn't modify anything reachable through its arguments, but is that true? How would you know? And how would you know if the API doc doesn't

Re: std.xml should just go

2011-02-04 Thread Steven Schveighoffer
On Fri, 04 Feb 2011 15:44:46 -0500, Jeff Nowakowski j...@dilacero.org wrote: On 02/03/2011 10:07 PM, Walter Bright wrote: The way to get a high performance string parser in D is to take advantage of one of D's unique features - slices. Java, C++, C#, etc., all rely on copying strings. With

Re: newcomer-friendly doc [was: Re: std.xml should just go]

2011-02-04 Thread Andrej Mitrovic
On 2/4/11, spir denis.s...@gmail.com wrote: but there are tons of parts of D2 that would benefit of a good introduction, really starting from the base (and not implicitely assuming 10 years of C++ programming --esp. about vocabulary: people here don't seem to realise how much words they use

Re: std.xml should just go

2011-02-04 Thread spir
On 02/04/2011 09:52 PM, so wrote: What would you do in the case of pointers to functions, virtual functions, functions implemented with inline assembly, and functions for which the source is not available? Just like we don't know if the derived class overrides a given function, we could do

Re: newcomer-friendly doc [was: Re: std.xml should just go]

2011-02-04 Thread spir
On 02/04/2011 10:41 PM, Andrej Mitrovic wrote: On 2/4/11, spirdenis.s...@gmail.com wrote: but there are tons of parts of D2 that would benefit of a good introduction, really starting from the base (and not implicitely assuming 10 years of C++ programming --esp. about vocabulary: people here

Re: std.xml should just go

2011-02-03 Thread Jacob Carlborg
On 2011-02-03 00:33, Andrei Alexandrescu wrote: For a while we've espoused the strategy of keeping std.xml in Phobos until something better comes along. But recently we've started to rethink that. Pretty much everyone who tries std.xml ends up disappointed. Anyone who wants to bash D has

Re: std.xml should just go

2011-02-03 Thread Jonathan M Davis
On Thursday 03 February 2011 02:01:35 Jacob Carlborg wrote: On 2011-02-03 00:33, Andrei Alexandrescu wrote: For a while we've espoused the strategy of keeping std.xml in Phobos until something better comes along. But recently we've started to rethink that. Pretty much everyone who

Re: std.xml should just go

2011-02-03 Thread Jacob Carlborg
On 2011-02-03 00:38, Daniel Gibson wrote: Am 03.02.2011 00:33, schrieb Andrei Alexandrescu: For a while we've espoused the strategy of keeping std.xml in Phobos until something better comes along. But recently we've started to rethink that. Pretty much everyone who tries std.xml ends up

Re: std.xml should just go

2011-02-03 Thread Jacob Carlborg
On 2011-02-03 01:47, Bernard Helyer wrote: On Wed, 02 Feb 2011 16:28:27 -0800, Brad Roberts wrote: I haven't used it nor am likely to, but I also have trouble ruling out the potential that there's users for which it works and they just aren't talking about it here. I do not believe that it's

Re: std.xml should just go

2011-02-03 Thread Masahiro Nakagawa
On Thu, 03 Feb 2011 08:33:42 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: For a while we've espoused the strategy of keeping std.xml in Phobos until something better comes along. But recently we've started to rethink that. Pretty much everyone who tries std.xml ends up

Re: std.xml should just go

2011-02-03 Thread Jonathan M Davis
On Thursday, February 03, 2011 11:30:17 Tomek Sowiński wrote: Andrei Alexandrescu napisał: I'm not against replacement, but I'd be concerned about removal before a replacement is available. My problem is that the mere presence is reducing the likelihood of a replacement coming about,

Re: std.xml should just go

2011-02-03 Thread Andrei Alexandrescu
On 2/3/11 1:30 PM, Tomek Sowiński wrote: Andrei Alexandrescu napisał: I'm not against replacement, but I'd be concerned about removal before a replacement is available. My problem is that the mere presence is reducing the likelihood of a replacement coming about, in addition to the other

Re: std.xml should just go

2011-02-03 Thread Tomek Sowiński
Andrei Alexandrescu napisał: Is anyone tasked with a replacement yet? I had to write an XML parser at some point. It's plenty of work bringing up to industrial quality, so I'd have to know that before I dive in. Nobody that I know of. If you want to discuss design here while working

Re: std.xml should just go

2011-02-03 Thread Tomek Sowiński
Jonathan M Davis napisał: I think that at least a couple of people have said that they have the beginnings of a replacement, but I don't believe that anyone has stepped up to say that they'll actually complete and propose a module for inclusion in Phobos. Wimps ;-) So, std.xml is still

Re: std.xml should just go

2011-02-03 Thread Steven Schveighoffer
On Thu, 03 Feb 2011 15:48:45 -0500, Tomek Sowiński j...@ask.me wrote: Jonathan M Davis napisał: I think that at least a couple of people have said that they have the beginnings of a replacement, but I don't believe that anyone has stepped up to say that they'll actually complete and

Re: std.xml should just go

2011-02-03 Thread Daniel Gibson
Am 03.02.2011 21:48, schrieb Tomek Sowiński: Jonathan M Davis napisał: I think that at least a couple of people have said that they have the beginnings of a replacement, but I don't believe that anyone has stepped up to say that they'll actually complete and propose a module for

Re: std.xml should just go

2011-02-03 Thread Jonathan M Davis
On Thursday 03 February 2011 12:48:45 Tomek Sowiński wrote: Jonathan M Davis napisał: I think that at least a couple of people have said that they have the beginnings of a replacement, but I don't believe that anyone has stepped up to say that they'll actually complete and propose a module

Re: std.xml should just go

2011-02-03 Thread spir
On 02/03/2011 10:00 PM, Steven Schveighoffer wrote: I believe it is a pull parser, though I'm not sure what that means. http://en.wikipedia.org/wiki/XML#Pull_parsing --- Denis -- _ vita es estrany spir.wikidot.com

Re: std.xml should just go

2011-02-03 Thread spir
On 02/03/2011 10:03 PM, Daniel Gibson wrote: You probably shouldn't look at the source. I dunno about the interface (documentation) - it's certainly not illegal to take inspiration from it, but maybe then people will again claim that source was stolen.. but when you claim that you haven't looked

Re: std.xml should just go

2011-02-03 Thread Steven Schveighoffer
On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson metalcae...@gmail.com wrote: Am 03.02.2011 21:48, schrieb Tomek Sowiński: Jonathan M Davis napisał: I think that at least a couple of people have said that they have the beginnings of a replacement, but I don't believe that anyone has

Re: std.xml should just go

2011-02-03 Thread Daniel Gibson
Am 03.02.2011 22:26, schrieb Steven Schveighoffer: On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson metalcae...@gmail.com wrote: Am 03.02.2011 21:48, schrieb Tomek Sowiński: Jonathan M Davis napisał: I think that at least a couple of people have said that they have the beginnings of a

Re: std.xml should just go

2011-02-03 Thread Gary Whatmore
Steven Schveighoffer Wrote: On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson metalcae...@gmail.com wrote: Am 03.02.2011 22:26, schrieb Steven Schveighoffer: On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson metalcae...@gmail.com wrote: Am 03.02.2011 21:48, schrieb Tomek

Re: std.xml should just go

2011-02-03 Thread Steven Schveighoffer
On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson metalcae...@gmail.com wrote: Am 03.02.2011 22:26, schrieb Steven Schveighoffer: On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson metalcae...@gmail.com wrote: Am 03.02.2011 21:48, schrieb Tomek Sowiński: Speaking of Tango, may I look at

Re: std.xml should just go

2011-02-03 Thread Tomek Sowiński
Daniel Gibson napisał: They can claim whatever they want.. if Tomek says he only looked at the documentation (for an idea how a good interface for a XML lib may look like) they can hardly prove anything. One remark: I haven't even looked at the doc. That's why I was asking may I look. --

Re: std.xml should just go

2011-02-03 Thread Daniel Gibson
Am 03.02.2011 22:45, schrieb Steven Schveighoffer: On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson metalcae...@gmail.com wrote: Am 03.02.2011 22:26, schrieb Steven Schveighoffer: On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson metalcae...@gmail.com wrote: Am 03.02.2011 21:48,

Re: std.xml should just go

2011-02-03 Thread Tomek Sowiński
spir spir napisał: You probably shouldn't look at the source. I dunno about the interface (documentation) - it's certainly not illegal to take inspiration from it, but maybe then people will again claim that source was stolen.. but when you claim that you haven't looked at the source

Re: std.xml should just go

2011-02-03 Thread Steven Schveighoffer
On Thu, 03 Feb 2011 17:10:18 -0500, Daniel Gibson metalcae...@gmail.com wrote: I thought the Author *had* looked at the Tango source but claimed not to have used it? See here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announcearticle_id=18090 His English

Re: std.xml should just go

2011-02-03 Thread Jonathan M Davis
On Thursday, February 03, 2011 13:51:41 Gary Whatmore wrote: Steven Schveighoffer Wrote: On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson metalcae...@gmail.com wrote: Am 03.02.2011 22:26, schrieb Steven Schveighoffer: On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson

Re: std.xml should just go

2011-02-03 Thread Andrei Alexandrescu
On 2/3/11 3:51 PM, Gary Whatmore wrote: Steven Schveighoffer Wrote: On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibsonmetalcae...@gmail.com wrote: Am 03.02.2011 22:26, schrieb Steven Schveighoffer: On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson metalcae...@gmail.com wrote: Am

Re: std.xml should just go

2011-02-03 Thread Daniel Gibson
Am 03.02.2011 23:29, schrieb Steven Schveighoffer: On Thu, 03 Feb 2011 17:10:18 -0500, Daniel Gibson metalcae...@gmail.com wrote: I thought the Author *had* looked at the Tango source but claimed not to have used it? See here:

Re: std.xml should just go

2011-02-03 Thread Jonathan M Davis
On Thursday, February 03, 2011 14:17:49 Tomek Sowiński wrote: spir spir napisał: You probably shouldn't look at the source. I dunno about the interface (documentation) - it's certainly not illegal to take inspiration from it, but maybe then people will again claim that source was

Re: std.xml should just go

2011-02-03 Thread Jonathan M Davis
On Thursday, February 03, 2011 14:36:06 Andrei Alexandrescu wrote: On 2/3/11 3:51 PM, Gary Whatmore wrote: Steven Schveighoffer Wrote: On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibsonmetalcae...@gmail.com wrote: Am 03.02.2011 22:26, schrieb Steven Schveighoffer: On Thu, 03 Feb 2011

Re: std.xml should just go

2011-02-03 Thread spir
On 02/03/2011 11:10 PM, Daniel Gibson wrote: Claiming that looking at the documentation isn't sufficient to understand how the API works (from a users point of view, not internally) is pretty stupid: 1. it insults the modules author(s) (You're too stupid to write meaningful documentation) 2.

Re: std.xml should just go

2011-02-03 Thread David Nadlinger
On 2/3/11 11:46 PM, Jonathan M Davis wrote: […] If they were more open and willing to share code, then building off of what they have and turning it into a range-based solution would likely make a lot of sense, but since that's not the case, we need to figure it out on our own. Just like

Re: std.xml should just go

2011-02-03 Thread Nick Sabalausky
Gary Whatmore n...@spam.sp wrote in message news:iif81d$1ch8$1...@digitalmars.com... Steven Schveighoffer Wrote: On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson metalcae...@gmail.com wrote: Am 03.02.2011 22:26, schrieb Steven Schveighoffer: On Thu, 03 Feb 2011 16:03:55 -0500, Daniel

Re: std.xml should just go

2011-02-03 Thread Steven Schveighoffer
On Thu, 03 Feb 2011 17:53:24 -0500, David Nadlinger s...@klickverbot.at wrote: On 2/3/11 11:46 PM, Jonathan M Davis wrote: […] If they were more open and willing to share code, then building off of what they have and turning it into a range-based solution would likely make a lot of sense,

Re: std.xml should just go

2011-02-03 Thread Nick Sabalausky
Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.vqcns2egeav7ka@steve-laptop... On Thu, 03 Feb 2011 17:53:24 -0500, David Nadlinger s...@klickverbot.at wrote: On 2/3/11 11:46 PM, Jonathan M Davis wrote: [.] If they were more open and willing to share code, then building

  1   2   >