www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Phobos packages a bit confusing

reply retard <re tard.com.invalid> writes:
Hi

after using D1 and Tango for couple of years we decided to experiment 
with D2 and Phobos in a small scale project. For some reason the mostly 
flat package hierarchy seemed rather confusing.

For instance, it took two of us 15 minutes to build a program that reads 
a line from user, converts the string to a natural number, adds one, and 
finally prints it to the screen. Entities like 'stdin' seem to have no 
documentation at all. What should I import to get it, what interfaces 
does it implement etc.

When writing this, I already forgot what package contained the to! 
template. My intuition says it should be in
 * std.stdint [int related operations]
 * std.format [number formats?]
 * std.typecons [we're constructing a int from a string]
 * std.string [the input was a string, maybe toInt is a string operation]
 * std.numeric [it's a numeric operation, isn't it]

I admit using higher level languages has made major damage to my brain 
("500.1".toInt anyone?), but still using Tango, Java, or C# seems rather 
intuitive, but in Phobos the set of packages and their contents feels 
more or less arbitrary. Is there anything that can be done?
Nov 29 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
retard Wrote:

 Hi
 
 after using D1 and Tango for couple of years we decided to experiment 
 with D2 and Phobos in a small scale project. For some reason the mostly 
 flat package hierarchy seemed rather confusing.
 
 For instance, it took two of us 15 minutes to build a program that reads 
 a line from user, converts the string to a natural number, adds one, and 
 finally prints it to the screen. Entities like 'stdin' seem to have no 
 documentation at all. What should I import to get it, what interfaces 
 does it implement etc.

That's an interesting example considering how Tango IO is way more complex. Comparatively speaking, 15 minutes is great! That being said, there probably are ways to make D2 Phobos easier to use.
 When writing this, I already forgot what package contained the to! 
 template. 

std.conv (for conversions)
 My intuition says it should be in
  * std.stdint [int related operations]
  * std.format [number formats?]
  * std.typecons [we're constructing a int from a string]
  * std.string [the input was a string, maybe toInt is a string operation]
  * std.numeric [it's a numeric operation, isn't it]
 
 I admit using higher level languages has made major damage to my brain 
 ("500.1".toInt anyone?), but still using Tango, Java, or C# seems rather 
 intuitive, but in Phobos the set of packages and their contents feels 
 more or less arbitrary. Is there anything that can be done?

Any massively used language is easier to use because a google search turns up similar code. I've found both D2 Phobos and Tango to be easy to use once you start. Tango was easier to find where most things were, but was amazingly tough to assemble generic pieces for IO. I remember reading line buffered text from standard in was way simpler with D2 Phobos.
Nov 29 2009
parent retard <re tard.com.invalid> writes:
Sun, 29 Nov 2009 14:36:24 -0500, Jason House wrote:

 retard Wrote:
 
 Hi
 
 after using D1 and Tango for couple of years we decided to experiment
 with D2 and Phobos in a small scale project. For some reason the mostly
 flat package hierarchy seemed rather confusing.
 
 For instance, it took two of us 15 minutes to build a program that
 reads a line from user, converts the string to a natural number, adds
 one, and finally prints it to the screen. Entities like 'stdin' seem to
 have no documentation at all. What should I import to get it, what
 interfaces does it implement etc.

That's an interesting example considering how Tango IO is way more complex. Comparatively speaking, 15 minutes is great! That being said, there probably are ways to make D2 Phobos easier to use.
 When writing this, I already forgot what package contained the to!
 template.

std.conv (for conversions)
 My intuition says it should be in
  * std.stdint [int related operations] * std.format [number formats?]
  * std.typecons [we're constructing a int from a string] * std.string
  [the input was a string, maybe toInt is a string operation] *
  std.numeric [it's a numeric operation, isn't it]
 
 I admit using higher level languages has made major damage to my brain
 ("500.1".toInt anyone?), but still using Tango, Java, or C# seems
 rather intuitive, but in Phobos the set of packages and their contents
 feels more or less arbitrary. Is there anything that can be done?

Any massively used language is easier to use because a google search turns up similar code. I've found both D2 Phobos and Tango to be easy to use once you start. Tango was easier to find where most things were, but was amazingly tough to assemble generic pieces for IO. I remember reading line buffered text from standard in was way simpler with D2 Phobos.

Agreed. Also, once you start memorizing stuff, it doesn't matter that much anymore what the functions are called and where they can be found. I found the tutorials on Tango's site very helpful when learning it. I also agree that doing common tasks is more straightforward with Phobos and the resulting code is also a bit shorter, but using Tango was a bit more intuitive.
Nov 29 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
retard wrote:
 Hi
 
 after using D1 and Tango for couple of years we decided to experiment 
 with D2 and Phobos in a small scale project. For some reason the mostly 
 flat package hierarchy seemed rather confusing.
 
 For instance, it took two of us 15 minutes to build a program that reads 
 a line from user, converts the string to a natural number, adds one, and 
 finally prints it to the screen. Entities like 'stdin' seem to have no 
 documentation at all. What should I import to get it, what interfaces 
 does it implement etc.
 
 When writing this, I already forgot what package contained the to! 
 template. My intuition says it should be in
  * std.stdint [int related operations]
  * std.format [number formats?]
  * std.typecons [we're constructing a int from a string]
  * std.string [the input was a string, maybe toInt is a string operation]
  * std.numeric [it's a numeric operation, isn't it]
 
 I admit using higher level languages has made major damage to my brain 
 ("500.1".toInt anyone?), but still using Tango, Java, or C# seems rather 
 intuitive, but in Phobos the set of packages and their contents feels 
 more or less arbitrary. Is there anything that can be done?

These are great points. I personally consider import files a necessary evil. There are a couple of things that make me hopeful about simplifying the situation: a) D parses fast enough to allow importing extensive modules; b) The "no-hijack" approach allows liberal importing of modules without fear of serious name clashes. Walter and I discussed quite a few times the possibility of defining std.all that publically imports all of std. My experiments show that a short script importing std.all will compile slower, but not too slow, compared to a script that only import a few modules. One other possibility would be to define some generic modules that group together useful lower-level modules. The question is of course how to name those aggregation modules (std.common?) and what they should include. Some PR or tips on how to search the documentation may also be helpful. If you navigate to Phobos' homepage http://digitalmars.com/d/2.0/phobos/phobos.html and then enter conversion in the search box, std.conv comes up first. Also, the same module comes up first if you search this with google: d programming language conversion It would be great to improve D and Phobos accessibility for first-time users. (To my personal satisfaction, searching google for std::algorithm puts D's std.algorithm in the third or fifth position (depending how you count), after the obligatory C++ reference sites.) Andrei
Nov 29 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Walter and I discussed quite a few times the possibility of defining
 std.all that publically imports all of std. My experiments show that a
 short script importing std.all will compile slower, but not too slow,
 compared to a script that only import a few modules.

Vote++. This would be a nice little convenience when writing small scripts in D, which I actually do quite often because I already know where basic APIs like file I/O are in Phobos and I don't want to learn another API just for small scripts. This goes along with the scaling down thing I was talking about a few days ago. A well-designed language and library should be good for both big projects (making complicated things possible) and small projects (making things simple). std.all would be a trivial addition that wouldn't clash with anything else and would really help Phobos scale down better.
Nov 29 2009
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from retard (re tard.com.invalid)'s article
 Sun, 29 Nov 2009 20:26:07 +0000, dsimcha wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
 article
 Walter and I discussed quite a few times the possibility of defining
 std.all that publically imports all of std. My experiments show that a
 short script importing std.all will compile slower, but not too slow,
 compared to a script that only import a few modules.

Vote++. This would be a nice little convenience when writing small scripts in D, which I actually do quite often because I already know where basic APIs like file I/O are in Phobos and I don't want to learn another API just for small scripts. This goes along with the scaling down thing I was talking about a few days ago. A well-designed language and library should be good for both big projects (making complicated things possible) and small projects (making things simple). std.all would be a trivial addition that wouldn't clash with anything else and would really help Phobos scale down better.

http://www.bpython-interpreter.org/screenshots/ Nicely integrated apidocs.

Yeah, I like Python, especially for things where I need tons of libraries that have simple APIs and are just there, or where I really need a dynamic language and even D templates aren't a good substitute. I do most of my coding in D, with Python as my second language for when D is just the wrong tool for the job. However, 1. I'm more used to D and it's almost as easy to use as Python. Therefore I tend to use D more for the "grab the quickest thing available and get it working" kind of programming. 2. I sometimes need to write tiny but fast programs, such as simple monte carlo simulations that I want to be able to tweak and run with as little thumb twiddling in between as possible, or utility programs that do some specific operation to a large amount of data. Since D's build times are negligible for these programs and D code runs much faster than Python, D is the better tool here. 3. I've built up a whole bunch of custom libraries in D that I like (the better/more universally useful ones I've released under various projects, the more quick and dirty or niche ones I haven't) and I want access to them even in very small scripts.
Nov 29 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
dsimcha wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Walter and I discussed quite a few times the possibility of defining
 std.all that publically imports all of std. My experiments show that a
 short script importing std.all will compile slower, but not too slow,
 compared to a script that only import a few modules.

Vote++. This would be a nice little convenience when writing small scripts in D, which I actually do quite often because I already know where basic APIs like file I/O are in Phobos and I don't want to learn another API just for small scripts. This goes along with the scaling down thing I was talking about a few days ago. A well-designed language and library should be good for both big projects (making complicated things possible) and small projects (making things simple). std.all would be a trivial addition that wouldn't clash with anything else and would really help Phobos scale down better.

Sounds great. I'm even more encouraged by some brief measurement results. I timed dmd against this program: void main(){} Then against this program: import std.stdio; void main(){} Then against this program: import std.stdio; void main(){} For convenience of other testers I'm pasting std.all after this message. The test machine is a 2.5 years old bottom-of-the-line Ubuntu laptop that seems to be in possession of the secret of immortality. Quiescent average run times: * 0.23 seconds for the first program * 0.64 seconds for the second program * 0.98 seconds for the third program I assume any program or script would have to include at least one module, and the marginal cost of including all other modules is low enough to be encouraging. Andrei module std.all; public import std.algorithm; public import std.array; //public import std.atomics; public import std.base64; public import std.bigint; public import std.bitmanip; public import std.boxer; public import std.compiler; public import std.complex; public import std.contracts; public import std.conv; public import std.cpuid; public import std.cstream; public import std.ctype; public import std.date; public import std.datebase; public import std.dateparse; public import std.demangle; public import std.encoding; public import std.file; public import std.format; public import std.functional; public import std.getopt; public import std.intrinsic; public import std.iterator; public import std.json; //public import std.loader; public import std.math; public import std.md5; public import std.metastrings; public import std.mmfile; public import std.numeric; public import std.outbuffer; public import std.path; public import std.perf; public import std.process; public import std.random; public import std.range; public import std.regex; public import std.regexp; public import std.signals; public import std.socket; public import std.socketstream; public import std.stdint; public import std.stdio; public import std.stdiobase; public import std.stream; public import std.string; public import std.syserror; public import std.system; public import std.traits; public import std.typecons; public import std.typetuple; public import std.uni; public import std.uri; public import std.utf; public import std.variant; public import std.xml; public import std.zip; public import std.zlib;
Nov 29 2009
prev sibling parent retard <re tard.com.invalid> writes:
Sun, 29 Nov 2009 20:26:07 +0000, dsimcha wrote:

 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
 article
 Walter and I discussed quite a few times the possibility of defining
 std.all that publically imports all of std. My experiments show that a
 short script importing std.all will compile slower, but not too slow,
 compared to a script that only import a few modules.

Vote++. This would be a nice little convenience when writing small scripts in D, which I actually do quite often because I already know where basic APIs like file I/O are in Phobos and I don't want to learn another API just for small scripts. This goes along with the scaling down thing I was talking about a few days ago. A well-designed language and library should be good for both big projects (making complicated things possible) and small projects (making things simple). std.all would be a trivial addition that wouldn't clash with anything else and would really help Phobos scale down better.

When writing small scripts, I use bpython: http://www.bpython-interpreter.org/screenshots/ Nicely integrated apidocs.
Nov 29 2009
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sun, Nov 29, 2009 at 07:12:50PM +0000, retard wrote:
 after using D1 and Tango for couple of years we decided to experiment 
 with D2 and Phobos in a small scale project. For some reason the mostly 
 flat package hierarchy seemed rather confusing.

Are you familiar with C's standard library? Phobos is loosely based on it, so if you can think of where you'd find it in C, it won't be far off in phobos.
 Entities like 'stdin' seem to have no 
 documentation at all. What should I import to get it, what interfaces 
 does it implement etc.

http://digitalmars.com/d/2.0/phobos/std_stdio.html#File stdin is just an instance of that struct - directly analogous to how stdin in C is a FILE*. (D actually used C's FILE* directly for the longest time.)
  * std.string [the input was a string, maybe toInt is a string operation]

That's where it used to be, but now the generic to!() template does it all, including non string types, so it gets its own module.
 I admit using higher level languages has made major damage to my brain 
 ("500.1".toInt anyone?), but still using Tango, Java, or C# seems rather 
 intuitive, but in Phobos the set of packages and their contents feels 
 more or less arbitrary. Is there anything that can be done?

I do think some more big picture overview like documentation pages would be a good idea. If I had more time, I'd write some of them myself. -- Adam D. Ruppe http://arsdnet.net
Nov 29 2009
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sun, 29 Nov 2009 15:30:14 -0500, Adam D. Ruppe wrote:

 On Sun, Nov 29, 2009 at 07:12:50PM +0000, retard wrote:
 after using D1 and Tango for couple of years we decided to experiment
 with D2 and Phobos in a small scale project. For some reason the mostly
 flat package hierarchy seemed rather confusing.

Are you familiar with C's standard library? Phobos is loosely based on it, so if you can think of where you'd find it in C, it won't be far off in phobos.

Nope, I come from Java/C# land.
 
 Entities like 'stdin' seem to have no documentation at all. What should
 I import to get it, what interfaces does it implement etc.

http://digitalmars.com/d/2.0/phobos/std_stdio.html#File

 stdin is just an instance of that struct - directly analogous to how
 stdin in C is a FILE*. (D actually used C's FILE* directly for the
 longest time.)

I got it now. Note that stdin and stdout aren't defined anywhere. They're mentioned only briefly in the examples of the informal documentation.
Nov 29 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:heuh3h$o71$3 digitalmars.com...
 Hi

 after using D1 and Tango for couple of years we decided to experiment
 with D2 and Phobos in a small scale project. For some reason the mostly
 flat package hierarchy seemed rather confusing.

 For instance, it took two of us 15 minutes to build a program that reads
 a line from user, converts the string to a natural number, adds one, and
 finally prints it to the screen. Entities like 'stdin' seem to have no
 documentation at all. What should I import to get it, what interfaces
 does it implement etc.

I actually find that kind of ironic, because that's pretty much how I feel about tango's ultra-separation-mania. I use tango all the time and I still can't do a single IO operation without spending at least ten minutes hunting blindly through the docs and finally finding what I need (including the necessary documentation) is spread out across at least three different modules.
Nov 29 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Nick Sabalausky (a a.a)'s article
 "retard" <re tard.com.invalid> wrote in message
 news:heuh3h$o71$3 digitalmars.com...
 Hi

 after using D1 and Tango for couple of years we decided to experiment
 with D2 and Phobos in a small scale project. For some reason the mostly
 flat package hierarchy seemed rather confusing.

 For instance, it took two of us 15 minutes to build a program that reads
 a line from user, converts the string to a natural number, adds one, and
 finally prints it to the screen. Entities like 'stdin' seem to have no
 documentation at all. What should I import to get it, what interfaces
 does it implement etc.

about tango's ultra-separation-mania. I use tango all the time and I still can't do a single IO operation without spending at least ten minutes hunting blindly through the docs and finally finding what I need (including the necessary documentation) is spread out across at least three different modules.

Yeah, I dislike Tango's (and Java's) I/O design. I think it's a classic example of overengineering. I don't care how efficient, flexible, complete, etc. it is if it doesn't "just work" for the simple stuff. By far the two most important pieces of I/O functionality I need are: 1. Read a text file line-by-line. 2. Read a whole file into an array of bytes. These are common, simple I/O operations that just about everyone needs fairly often. It's ridiculous if I have to use three different modules or whatever it takes to accomplish something so simple. I'm convinced that this is one thing that turns a lot of people off to programming if they get past the first hurdle of understanding variable assignment. File I/O is required for almost any program complicated enough to be worth writing. When a beginner who doesn't necessarily even understand the concept of a class hierarchy well sees a huge overengineered API for basic file I/O, he/she is bound to think (wrongly) that programming is much harder than it really is and that he/she is just inept at it.
Nov 29 2009
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Nov 30, 09 14:02, retard wrote:
 Mon, 30 Nov 2009 04:51:19 +0000, dsimcha wrote:

 == Quote from Nick Sabalausky (a a.a)'s article
 "retard"<re tard.com.invalid>  wrote in message
 news:heuh3h$o71$3 digitalmars.com...
 Hi

 after using D1 and Tango for couple of years we decided to experiment
 with D2 and Phobos in a small scale project. For some reason the
 mostly flat package hierarchy seemed rather confusing.

 For instance, it took two of us 15 minutes to build a program that
 reads a line from user, converts the string to a natural number, adds
 one, and finally prints it to the screen. Entities like 'stdin' seem
 to have no documentation at all. What should I import to get it, what
 interfaces does it implement etc.

feel about tango's ultra-separation-mania. I use tango all the time and I still can't do a single IO operation without spending at least ten minutes hunting blindly through the docs and finally finding what I need (including the necessary documentation) is spread out across at least three different modules.

Yeah, I dislike Tango's (and Java's) I/O design. I think it's a classic example of overengineering. I don't care how efficient, flexible, complete, etc. it is if it doesn't "just work" for the simple stuff.

Are you sure you know what you're talking about?
 By
 far the two most important pieces of I/O functionality I need are:

 1.  Read a text file line-by-line.

foreach (line; new Lines!(char) (new File ("foobar.txt"))) Cout (line).newline; }

yuck.
 2.  Read a whole file into an array of bytes.

new File("foobar.bin").read() Java isn't that bad IMO - you just have to remember the buffer: BufferedReader input = new BufferedReader(new FileReader("foo")); try { String line = null; while (( line = input.readLine()) != null) { } } finally { input.close(); }

yuck yuck yuck.
 These are common, simple I/O operations that just about everyone needs
 fairly often.  It's ridiculous if I have to use three different modules
 or whatever it takes to accomplish something so simple.

 I'm convinced that this is one thing that turns a lot of people off to
 programming if they get past the first hurdle of understanding variable
 assignment.  File I/O is required for almost any program complicated
 enough to be worth writing.  When a beginner who doesn't necessarily
 even understand the concept of a class hierarchy well sees a huge
 overengineered API for basic file I/O, he/she is bound to think
 (wrongly) that programming is much harder than it really is and that
 he/she is just inept at it.

Well, that's not the only problem a novice meets during the first minutes / hours with a new language. If you write e.g. console apps for win32, you need to teach them what code pages are, why do you need to convert between utf-8 and windows-1252 etc. since the default console i/o routines are not unicode aware under windows.

Nov 30 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
KennyTM~ wrote:
 By
 far the two most important pieces of I/O functionality I need are:

 1.  Read a text file line-by-line.

foreach (line; new Lines!(char) (new File ("foobar.txt"))) Cout (line).newline; }

yuck.

Yuck?? I find that code very elegant. How would you like it to be?
Nov 30 2009
next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Ary Borenszweig wrote:
 KennyTM~ wrote:
 By
 far the two most important pieces of I/O functionality I need are:

 1.  Read a text file line-by-line.

foreach (line; new Lines!(char) (new File ("foobar.txt"))) Cout (line).newline; }

yuck.

Yuck?? I find that code very elegant. How would you like it to be?

I wouldn't go as far as saying "yuck" to the above, but I like the Phobos way better: foreach (line; File("foobar.txt").byLine) { ... } -Lars
Nov 30 2009
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Nov 30, 09 19:01, Ary Borenszweig wrote:
 KennyTM~ wrote:
 By
 far the two most important pieces of I/O functionality I need are:

 1. Read a text file line-by-line.

foreach (line; new Lines!(char) (new File ("foobar.txt"))) Cout (line).newline; }

yuck.

Yuck?? I find that code very elegant. How would you like it to be?

Python do it like this: for line in open("foobar.txt"): print(line) How many things you need to explain for that elegant code? Line? File? Cout? .newline?
Nov 30 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
retard wrote:
 Mon, 30 Nov 2009 21:06:21 +0800, KennyTM~ wrote:
 
 On Nov 30, 09 19:01, Ary Borenszweig wrote:
 KennyTM~ wrote:
 By
 far the two most important pieces of I/O functionality I need are:

 1. Read a text file line-by-line.

(line).newline; }



for line in open("foobar.txt"): print(line) How many things you need to explain for that elegant code? Line? File? Cout? .newline?

Your argumentation is getting ridiculous. Reading and printing lines of a text file isn't by any means a good measure of standard library quality. I could define something like void printFileLines(string fn) { ... } in my code and use it like this: printFileLines("foobar.txt"); When I'm programming with a systems programming language, I really do want to know if it reads the whole 100 GB file into memory before iterating or if not, what kind of buffer it is using. I often also need to work with endianess issues, codepage conversions, file system exceptions etc. If I only need to write simple code (== programming in the small) I might want to use some scripting language instead. It's really hard to please both audiences without cluttering the stdlib api.

I don't have much time to spend on std.stdio nowadays, but the clear intent there is to provide range-based access that satisfies both audiences by using a good abstraction instead of cluttering the API. Andrei
Nov 30 2009
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from retard (re tard.com.invalid)'s article
 Mon, 30 Nov 2009 21:06:21 +0800, KennyTM~ wrote:
 On Nov 30, 09 19:01, Ary Borenszweig wrote:
 KennyTM~ wrote:
 By
 far the two most important pieces of I/O functionality I need are:

 1. Read a text file line-by-line.

foreach (line; new Lines!(char) (new File ("foobar.txt"))) Cout (line).newline; }


Yuck?? I find that code very elegant. How would you like it to be?

Python do it like this: for line in open("foobar.txt"): print(line) How many things you need to explain for that elegant code? Line? File? Cout? .newline?

text file isn't by any means a good measure of standard library quality. I could define something like void printFileLines(string fn) { ... } in my code and use it like this: printFileLines("foobar.txt"); When I'm programming with a systems programming language, I really do want to know if it reads the whole 100 GB file into memory before iterating or if not, what kind of buffer it is using. I often also need to work with endianess issues, codepage conversions, file system exceptions etc. If I only need to write simple code (== programming in the small) I might want to use some scripting language instead. It's really hard to please both audiences without cluttering the stdlib api.

Right, but I do scientific work. I've never written a polished app that's designed to be used by non-programmers or to be internationalized, where caring about things like unicode is important. Most of my programming is very algorithm-centric and CPU-bound. Anything I/O is generally regarded as just a means of getting data in to process it with your algorithms. The algorithms are where I want to spend about 99% of my coding efforts, but I need a systems language here for performance reasons. For I/O I just want the quickest, simplest thing available. If the character set supports A, C, T, G, and U (the five characters of DNA and RNA), it's good enough for me. I'm sure other niches have similar things: Dead simple requirements in one dimension, but need for a full-fledged systems language to fulfill requirements in another dimension. For example, I work with huge datasets and need to tune memory management pretty frequently. Someone writing business software might care more about unicode and "proper" I/O than I do, but probably wouldn't care at all about the ability to tune memory management. Maybe their need for a systems language is because they want native binaries or an easy way to interface with C code.
Nov 30 2009
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from dsimcha (dsimcha yahoo.com)'s article
 == Quote from retard (re tard.com.invalid)'s article
 Mon, 30 Nov 2009 21:06:21 +0800, KennyTM~ wrote:
 On Nov 30, 09 19:01, Ary Borenszweig wrote:
 KennyTM~ wrote:
 By
 far the two most important pieces of I/O functionality I need are:

 1. Read a text file line-by-line.

foreach (line; new Lines!(char) (new File ("foobar.txt"))) Cout (line).newline; }


Yuck?? I find that code very elegant. How would you like it to be?

Python do it like this: for line in open("foobar.txt"): print(line) How many things you need to explain for that elegant code? Line? File? Cout? .newline?

text file isn't by any means a good measure of standard library quality. I could define something like void printFileLines(string fn) { ... } in my code and use it like this: printFileLines("foobar.txt"); When I'm programming with a systems programming language, I really do want to know if it reads the whole 100 GB file into memory before iterating or if not, what kind of buffer it is using. I often also need to work with endianess issues, codepage conversions, file system exceptions etc. If I only need to write simple code (== programming in the small) I might want to use some scripting language instead. It's really hard to please both audiences without cluttering the stdlib api.

designed to be used by non-programmers or to be internationalized, where caring about things like unicode is important. Most of my programming is very algorithm-centric and CPU-bound. Anything I/O is generally regarded as just a means of getting data in to process it with your algorithms. The algorithms are where I want to spend about 99% of my coding efforts, but I need a systems language here for performance reasons. For I/O I just want the quickest, simplest thing available. If the character set supports A, C, T, G, and U (the five characters of DNA and RNA), it's good enough for me. I'm sure other niches have similar things: Dead simple requirements in one dimension, but need for a full-fledged systems language to fulfill requirements in another dimension. For example, I work with huge datasets and need to tune memory management pretty frequently. Someone writing business software might care more about unicode and "proper" I/O than I do, but probably wouldn't care at all about the ability to tune memory management. Maybe their need for a systems language is because they want native binaries or an easy way to interface with C code.

I guess the idea here is that the beauty of D2/Phobos is that it's a systems programming language/lib, but one that only makes you care that it's a systems programming language for the parts of your code where you really need the power of a systems language. For the parts of your code where that power is overkill, you can seamlessly shift into a more scripting language style of programming, without any messy glue layers, inter-language interfaces, etc. getting in the way.
Nov 30 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
retard wrote:
 Mon, 30 Nov 2009 12:01:22 +0100, Ary Borenszweig wrote:
 
 KennyTM~ wrote:
 By
 far the two most important pieces of I/O functionality I need are:

 1.  Read a text file line-by-line.

Cout (line).newline; }



I guess something like this: JustDoItWith("foobar.txt") { ... }

foreach (char[] line; File("text.txt").byLine()) { ... } Efficient, flexible, convenient. Closes automatically the file, too, which Tango seems doesn't. Andrei
Nov 30 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Mon, 30 Nov 2009 18:25:41 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 retard wrote:
 Mon, 30 Nov 2009 12:01:22 +0100, Ary Borenszweig wrote:

 KennyTM~ wrote:
 By
 far the two most important pieces of I/O functionality I need are:

 1.  Read a text file line-by-line.

Cout (line).newline; }



JustDoItWith("foobar.txt") { ... }

foreach (char[] line; File("text.txt").byLine()) { ... } Efficient, flexible, convenient. Closes automatically the file, too, which Tango seems doesn't. Andrei

If it closes file automatically, then why do you close it explicitly in slurp?

Because a compiler bug prevented the destructor from functioning correctly. The manual close does no harm now but of course should be removed.
 The code is almost the same except that "Lines" class works with any 
 Input Stream (memory stream, file stream, network stream, pipe, i/o 
 device etc).

I hope we'd be able to add such streams to Phobos too, perhaps using your networking library for transport. Andrei
Nov 30 2009
prev sibling parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
Ary Borenszweig wrote:
 KennyTM~ wrote:
 By
 far the two most important pieces of I/O functionality I need are:

 1.  Read a text file line-by-line.

foreach (line; new Lines!(char) (new File ("foobar.txt"))) Cout (line).newline; }

yuck.

Yuck?? I find that code very elegant. How would you like it to be?

writeln(line); } I find the .newline idea rather hackish.
Nov 30 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Pelle Månsson:

 foreach (line; open("foobar.txt")) {
    writeln(line);
 }

With the xio module of my dlibs: import d.xio: xfile; foreach (line; xfile("foobar.txt")) putr(line); xfile is optimized to reduce memory rellocations as much as possible in the most common case of about 90 chars long lines. There is an xstdin too. Bye, bearophile
Nov 30 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Pelle Månsson:
 
 foreach (line; open("foobar.txt")) {
    writeln(line);
 }

With the xio module of my dlibs: import d.xio: xfile; foreach (line; xfile("foobar.txt")) putr(line); xfile is optimized to reduce memory rellocations as much as possible in the most common case of about 90 chars long lines. There is an xstdin too.

Why not just reuse the same buffer as the previous line? That approach is inherently adaptive. And why is there a need for xstdin vs. xfile? Stdin _is_ a file. Andrei
Nov 30 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 Why not just reuse the same buffer as the previous line? That approach 
 is inherently adaptive.

That approach is unsafe. xfile yields byte strings, in D1. When I write 10 lines long scripts I usually don't need every bit of optimization, I need the less bug-prone code as possible, because the thing I have to optimize is my coding time. In D1 strings are mutable, so if you put them in an AA as keys you must dup them to avoid bugs if you reuse the same buffer.
And why is there a need for xstdin vs. xfile? Stdin _is_ a file.<

I use it like this: foreach (line; xstdin) { ... } line is a string with newline at the end. I know this isn't the best design, but it's the most handy for my purposes. I need to do a limited number of things in those scripts and iterating over the lines of a fine and over the lines of the stdin are the only two that matter. Bye, bearophile
Nov 30 2009
parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
bearophile wrote:
 Andrei Alexandrescu:
 Why not just reuse the same buffer as the previous line? That approach 
 is inherently adaptive.

That approach is unsafe. xfile yields byte strings, in D1. When I write 10 lines long scripts I usually don't need every bit of optimization, I need the less bug-prone code as possible, because the thing I have to optimize is my coding time. In D1 strings are mutable, so if you put them in an AA as keys you must dup them to avoid bugs if you reuse the same buffer.

You'll have to .dup them if you want to use them as non-views always. I for one like that approach more. Why call it xfile and not just open?
 And why is there a need for xstdin vs. xfile? Stdin _is_ a file.<

I use it like this: foreach (line; xstdin) { ... } line is a string with newline at the end. I know this isn't the best design, but it's the most handy for my purposes. I need to do a limited number of things in those scripts and iterating over the lines of a fine and over the lines of the stdin are the only two that matter. Bye, bearophile

Dec 01 2009
parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
Denis Koroskin wrote:
 On Tue, 01 Dec 2009 15:22:23 +0300, Pelle Månsson 
 <pelle.mansson gmail.com> wrote:
 
 bearophile wrote:
 Andrei Alexandrescu:
 Why not just reuse the same buffer as the previous line? That 
 approach is inherently adaptive.

write 10 lines long scripts I usually don't need every bit of optimization, I need the less bug-prone code as possible, because the thing I have to optimize is my coding time. In D1 strings are mutable, so if you put them in an AA as keys you must dup them to avoid bugs if you reuse the same buffer.

You'll have to .dup them if you want to use them as non-views always. I for one like that approach more. Why call it xfile and not just open?
 And why is there a need for xstdin vs. xfile? Stdin _is_ a file.<

foreach (line; xstdin) { ... } line is a string with newline at the end. I know this isn't the best design, but it's the most handy for my purposes. I need to do a limited number of things in those scripts and iterating over the lines of a fine and over the lines of the stdin are the only two that matter. Bye, bearophile


In his notation, xfoo is a lazy version of foo (i.e. it reads file in chunks as opposed to reading the whole file at once). So you are essentially asking, "why file instead of open?". What's the difference? It's a bikeshed discussion, but I believe file("filename") is more clear than open("filename"). Besides, I'm used to "close" everything I "open", which is not suitable here/.

File looks like a constructor. You are not constructing a file you open for reading. Also, saying that you close everything you open, are you deallocating everything you allocate as well? I feel we have moved past such symmetry.
Dec 01 2009
parent reply Rainer Deyke <rainerd eldwood.com> writes:
Pelle Månsson wrote:
 File looks like a constructor. You are not constructing a file you open
 for reading.

"open" by itself is ambiguous. What are you opening? A window? A network port? I think the word "file" needs to be in there somewhere to disambiguate. -- Rainer Deyke - rainerd eldwood.com
Dec 01 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Rainer Deyke:
 "open" by itself is ambiguous.  What are you opening?  A window?  A
 network port?  I think the word "file" needs to be in there somewhere to
 disambiguate.

When you program in Python you remember that open is a built-in function to open files :-) When you want to open other things you import other names from some module. So this ambiguity usually doesn't introduce bugs. It' a well known convention. Few well chosen conventions (sensible defaults) save you from a lot of useless coding. Bye, bearophile
Dec 01 2009
next sibling parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
retard wrote:
 Tue, 01 Dec 2009 18:58:25 -0500, bearophile wrote:
 
 Rainer Deyke:
 "open" by itself is ambiguous.  What are you opening?  A window?  A
 network port?  I think the word "file" needs to be in there somewhere
 to disambiguate.

to open files :-) When you want to open other things you import other names from some module. So this ambiguity usually doesn't introduce bugs. It' a well known convention. Few well chosen conventions (sensible defaults) save you from a lot of useless coding.

These default values are sometimes very annoying. For instance almost in every game you have a game object hierarchy and the super class of game objects usually conflicts with built-in 'Object'. If I write an adventure game and some event opens a dungeon door, open() suddenly deals with files. Also IIRC Python has built-in print() command. What if I want to redefine this to mean printing to a graphical quake like game console. Namespaces in general seem rather useful. I hate the php like 'there's a flat global scope and everything is a free function approach'. It's annoying me each time I use phobos.

door.open() ? In python, you can just override what open does if you need open(door).
Dec 01 2009
parent =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
retard wrote:
 Wed, 02 Dec 2009 08:38:29 +0100, Pelle Månsson wrote:
 
 retard wrote:
 Tue, 01 Dec 2009 18:58:25 -0500, bearophile wrote:

 Rainer Deyke:
 "open" by itself is ambiguous.  What are you opening?  A window?  A
 network port?  I think the word "file" needs to be in there somewhere
 to disambiguate.

function to open files :-) When you want to open other things you import other names from some module. So this ambiguity usually doesn't introduce bugs. It' a well known convention. Few well chosen conventions (sensible defaults) save you from a lot of useless coding.

in every game you have a game object hierarchy and the super class of game objects usually conflicts with built-in 'Object'. If I write an adventure game and some event opens a dungeon door, open() suddenly deals with files. Also IIRC Python has built-in print() command. What if I want to redefine this to mean printing to a graphical quake like game console. Namespaces in general seem rather useful. I hate the php like 'there's a flat global scope and everything is a free function approach'. It's annoying me each time I use phobos.

need open(door).

In internal class methods the door.open can be written as this.open() or just open(). In that case you need to worry about other symbols, if they are globally available built-ins.

if it is ambiguous, the compiler will tell you so.
Dec 02 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:
 Namespaces in general seem rather useful. I hate the php like 'there's a 
 flat global scope and everything is a free function approach'. It's 
 annoying me each time I use phobos.

If you have the same name declared in multiple imports, you cannot refer to it without qualification (unless the function arguments are clearly distinct). I don't see the problem you are. Can you explain?
Dec 01 2009
prev sibling parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
Rainer Deyke wrote:
 Pelle Månsson wrote:
 File looks like a constructor. You are not constructing a file you open
 for reading.

"open" by itself is ambiguous. What are you opening? A window? A network port? I think the word "file" needs to be in there somewhere to disambiguate.

unambiguous. I'll rather have open as a file-opening function.
Dec 01 2009
parent reply Rainer Deyke <rainerd eldwood.com> writes:
Pelle Månsson wrote:
 Rainer Deyke wrote:
 "open" by itself is ambiguous.  What are you opening?  A window?  A
 network port?  I think the word "file" needs to be in there somewhere to
 disambiguate.

unambiguous.

No, like 'file("foo.txt")' or 'fopen("foo.txt")'. There's always a trade-off between verbosity and clarity, but names that are both reasonably short and reasonably unambiguous exist. -- Rainer Deyke - rainerd eldwood.com
Dec 02 2009
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Rainer Deyke wrote:
 Pelle M=C3=A5nsson wrote:
 Rainer Deyke wrote:
 "open" by itself is ambiguous.  What are you opening?  A window?  A
 network port?  I think the word "file" needs to be in there somewhere=



 disambiguate.



 unambiguous.

No, like 'file("foo.txt")' or 'fopen("foo.txt")'. There's always a trade-off between verbosity and clarity, but names that are both reasonably short and reasonably unambiguous exist. =20

for opening a file (unbuffered). Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Dec 02 2009
prev sibling next sibling parent torhu <no spam.invalid> writes:
On 30.11.2009 7:02, retard wrote:
 foreach (line; new Lines!(char) (new File ("foobar.txt")))
    Cout (line).newline;
 }

To be fair, it's a bit simpler than that in Tango: foreach (line; new TextFileInput("foobar.txt")) Cout (line).newline; }
  2.  Read a whole file into an array of bytes.

new File("foobar.bin").read()

This one too: auto contents = File.get("foobar.bin"); get is a static method in the File class. But I won't pretend that I think Tango I/O is easy to use. There's a lot of interfaces and classes, and usually several ways to accomplish the same thing. Some classes are just thin wrappers over others, which can be confusing.
Dec 01 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
retard wrote:
 Mon, 30 Nov 2009 04:51:19 +0000, dsimcha wrote:
 By
 far the two most important pieces of I/O functionality I need are:

 1.  Read a text file line-by-line.

foreach (line; new Lines!(char) (new File ("foobar.txt"))) Cout (line).newline; }
 2.  Read a whole file into an array of bytes.

new File("foobar.bin").read() Java isn't that bad IMO - you just have to remember the buffer: BufferedReader input = new BufferedReader(new FileReader("foo")); try { String line = null; while (( line = input.readLine()) != null) { } } finally { input.close(); }

Wouldn't you need a try/finally around the D code too? Andrei
Dec 05 2009
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Mon, 30 Nov 2009 04:51:19 +0000, dsimcha wrote:

 == Quote from Nick Sabalausky (a a.a)'s article
 "retard" <re tard.com.invalid> wrote in message
 news:heuh3h$o71$3 digitalmars.com...
 Hi

 after using D1 and Tango for couple of years we decided to experiment
 with D2 and Phobos in a small scale project. For some reason the
 mostly flat package hierarchy seemed rather confusing.

 For instance, it took two of us 15 minutes to build a program that
 reads a line from user, converts the string to a natural number, adds
 one, and finally prints it to the screen. Entities like 'stdin' seem
 to have no documentation at all. What should I import to get it, what
 interfaces does it implement etc.

feel about tango's ultra-separation-mania. I use tango all the time and I still can't do a single IO operation without spending at least ten minutes hunting blindly through the docs and finally finding what I need (including the necessary documentation) is spread out across at least three different modules.

Yeah, I dislike Tango's (and Java's) I/O design. I think it's a classic example of overengineering. I don't care how efficient, flexible, complete, etc. it is if it doesn't "just work" for the simple stuff.

Are you sure you know what you're talking about?
 By
 far the two most important pieces of I/O functionality I need are:
 
 1.  Read a text file line-by-line.

foreach (line; new Lines!(char) (new File ("foobar.txt"))) Cout (line).newline; }
 2.  Read a whole file into an array of bytes.

new File("foobar.bin").read() Java isn't that bad IMO - you just have to remember the buffer: BufferedReader input = new BufferedReader(new FileReader("foo")); try { String line = null; while (( line = input.readLine()) != null) { } } finally { input.close(); }
 
 These are common, simple I/O operations that just about everyone needs
 fairly often.  It's ridiculous if I have to use three different modules
 or whatever it takes to accomplish something so simple.
 
 I'm convinced that this is one thing that turns a lot of people off to
 programming if they get past the first hurdle of understanding variable
 assignment.  File I/O is required for almost any program complicated
 enough to be worth writing.  When a beginner who doesn't necessarily
 even understand the concept of a class hierarchy well sees a huge
 overengineered API for basic file I/O, he/she is bound to think
 (wrongly) that programming is much harder than it really is and that
 he/she is just inept at it.

Well, that's not the only problem a novice meets during the first minutes / hours with a new language. If you write e.g. console apps for win32, you need to teach them what code pages are, why do you need to convert between utf-8 and windows-1252 etc. since the default console i/o routines are not unicode aware under windows.
Nov 29 2009
parent "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:hevn56$2to1$1 digitalmars.com...
 Mon, 30 Nov 2009 04:51:19 +0000, dsimcha wrote:
 Yeah, I dislike Tango's (and Java's) I/O design.  I think it's a classic
 example of overengineering.  I don't care how efficient, flexible,
 complete, etc. it is if it doesn't "just work" for the simple stuff.

Are you sure you know what you're talking about?
 By
 far the two most important pieces of I/O functionality I need are:

 1.  Read a text file line-by-line.

foreach (line; new Lines!(char) (new File ("foobar.txt"))) Cout (line).newline; }
 2.  Read a whole file into an array of bytes.

new File("foobar.bin").read()

Sure, once you actually know that and remember it. But trying to discover them in the first place (and discover what modules to import, and how many are needed for #1 up there?) through the API reference is a royal PITA. Part of the problem is that there's about million different classes, modules, structs, functions, whatever all dealing with accessing a file. So I have to figure out which method to use, which is made extra painful by the fact that each way of going about it is spread out across at least three different modules out of a total of I-don't-even-want-to-count. And of course there are zero "all" modules which just leaves me bouncing back up to the imports section of my code every time I make an edit. "But it's right there in the tutorials, don't go looking through the API ref for it!" Well, ok, but there have been a lot of things I've needed to find (such as more in depth details) that the tuts don't tell me, and that I've had to look through the API ref or even source to find. So now I have to worry about not only what module to look in for what I want, but also which set of docs.
Nov 30 2009
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Mon, 30 Nov 2009 12:01:22 +0100, Ary Borenszweig wrote:

 KennyTM~ wrote:
 By
 far the two most important pieces of I/O functionality I need are:

 1.  Read a text file line-by-line.

foreach (line; new Lines!(char) (new File ("foobar.txt"))) Cout (line).newline; }


Yuck?? I find that code very elegant. How would you like it to be?

I guess something like this: JustDoItWith("foobar.txt") { ... }
Nov 30 2009
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Mon, 30 Nov 2009 21:06:21 +0800, KennyTM~ wrote:

 On Nov 30, 09 19:01, Ary Borenszweig wrote:
 KennyTM~ wrote:
 By
 far the two most important pieces of I/O functionality I need are:

 1. Read a text file line-by-line.

foreach (line; new Lines!(char) (new File ("foobar.txt"))) Cout (line).newline; }


Yuck?? I find that code very elegant. How would you like it to be?

Python do it like this: for line in open("foobar.txt"): print(line) How many things you need to explain for that elegant code? Line? File? Cout? .newline?

Your argumentation is getting ridiculous. Reading and printing lines of a text file isn't by any means a good measure of standard library quality. I could define something like void printFileLines(string fn) { ... } in my code and use it like this: printFileLines("foobar.txt"); When I'm programming with a systems programming language, I really do want to know if it reads the whole 100 GB file into memory before iterating or if not, what kind of buffer it is using. I often also need to work with endianess issues, codepage conversions, file system exceptions etc. If I only need to write simple code (== programming in the small) I might want to use some scripting language instead. It's really hard to please both audiences without cluttering the stdlib api.
Nov 30 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 30 Nov 2009 18:25:41 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 retard wrote:
 Mon, 30 Nov 2009 12:01:22 +0100, Ary Borenszweig wrote:

 KennyTM~ wrote:
 By
 far the two most important pieces of I/O functionality I need are:

 1.  Read a text file line-by-line.

Cout (line).newline; }



JustDoItWith("foobar.txt") { ... }

foreach (char[] line; File("text.txt").byLine()) { ... } Efficient, flexible, convenient. Closes automatically the file, too, which Tango seems doesn't. Andrei

If it closes file automatically, then why do you close it explicitly in slurp? The code is almost the same except that "Lines" class works with any Input Stream (memory stream, file stream, network stream, pipe, i/o device etc).
Nov 30 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 01 Dec 2009 15:22:23 +0300, Pelle M=C3=A5nsson  =

<pelle.mansson gmail.com> wrote:

 bearophile wrote:
 Andrei Alexandrescu:
 Why not just reuse the same buffer as the previous line? That approa=



 is inherently adaptive.



 write 10 lines long scripts I usually don't need every bit of  =


 optimization, I need the less bug-prone code as possible, because the=


 thing I have to optimize is my coding time. In D1 strings are mutable=


 so if you put them in an AA as keys you must dup them to avoid bugs i=


 you reuse the same buffer.

You'll have to .dup them if you want to use them as non-views always. =

 for one like that approach more.

 Why call it xfile and not just open?

 And why is there a need for xstdin vs. xfile? Stdin _is_ a file.<

foreach (line; xstdin) { ... } line is a string with newline at the end. I know this isn't the best design, but it's the most handy for my =


 purposes. I need to do a limited number of things in those scripts an=


 iterating over the lines of a fine and over the lines of the stdin ar=


 the only two that matter.
  Bye,
 bearophile


In his notation, xfoo is a lazy version of foo (i.e. it reads file in = chunks as opposed to reading the whole file at once). So you are essentially asking, "why file instead of open?". What's the = difference? It's a bikeshed discussion, but I believe file("filename") i= s = more clear than open("filename"). Besides, I'm used to "close" everythin= g = I "open", which is not suitable here.
Dec 01 2009
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Tue, 01 Dec 2009 18:58:25 -0500, bearophile wrote:

 Rainer Deyke:
 "open" by itself is ambiguous.  What are you opening?  A window?  A
 network port?  I think the word "file" needs to be in there somewhere
 to disambiguate.

When you program in Python you remember that open is a built-in function to open files :-) When you want to open other things you import other names from some module. So this ambiguity usually doesn't introduce bugs. It' a well known convention. Few well chosen conventions (sensible defaults) save you from a lot of useless coding.

These default values are sometimes very annoying. For instance almost in every game you have a game object hierarchy and the super class of game objects usually conflicts with built-in 'Object'. If I write an adventure game and some event opens a dungeon door, open() suddenly deals with files. Also IIRC Python has built-in print() command. What if I want to redefine this to mean printing to a graphical quake like game console. Namespaces in general seem rather useful. I hate the php like 'there's a flat global scope and everything is a free function approach'. It's annoying me each time I use phobos.
Dec 01 2009
parent bearophile <bearophileHUGS lycos.com> writes:
retard:
 Also IIRC Python has built-in print() command. What if I want to 
 redefine this to mean printing to a graphical quake like game console.

In Python3 there is a built-in print function, that is a reference to a callable object. So you just need to redefine it, like this: def print(...): # my stuff Or just: def foo(): ... print = foo Bye, bearophile
Dec 02 2009
prev sibling parent retard <re tard.com.invalid> writes:
Wed, 02 Dec 2009 08:38:29 +0100, Pelle Månsson wrote:

 retard wrote:
 Tue, 01 Dec 2009 18:58:25 -0500, bearophile wrote:
 
 Rainer Deyke:
 "open" by itself is ambiguous.  What are you opening?  A window?  A
 network port?  I think the word "file" needs to be in there somewhere
 to disambiguate.

function to open files :-) When you want to open other things you import other names from some module. So this ambiguity usually doesn't introduce bugs. It' a well known convention. Few well chosen conventions (sensible defaults) save you from a lot of useless coding.

These default values are sometimes very annoying. For instance almost in every game you have a game object hierarchy and the super class of game objects usually conflicts with built-in 'Object'. If I write an adventure game and some event opens a dungeon door, open() suddenly deals with files. Also IIRC Python has built-in print() command. What if I want to redefine this to mean printing to a graphical quake like game console. Namespaces in general seem rather useful. I hate the php like 'there's a flat global scope and everything is a free function approach'. It's annoying me each time I use phobos.

door.open() ? In python, you can just override what open does if you need open(door).

In internal class methods the door.open can be written as this.open() or just open(). In that case you need to worry about other symbols, if they are globally available built-ins.
Dec 01 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from retard (re tard.com.invalid)'s article
 Hi
 after using D1 and Tango for couple of years we decided to experiment
 with D2 and Phobos in a small scale project. For some reason the mostly
 flat package hierarchy seemed rather confusing.
 For instance, it took two of us 15 minutes to build a program that reads
 a line from user, converts the string to a natural number, adds one, and
 finally prints it to the screen.

While I agree that the docs for Phobos should be improved after the language stabilizes, I honestly don't think 15 minutes is too bad if you're completely unfamiliar with the API. Using Java's file I/O API, for example, practically requires a Ph.D. in object-oriented design. It's just a fact of life that every API has its quirks that take time to learn, and anything that's not what you're used to is going to seem quirky at first.
Nov 29 2009
parent reply retard <re tard.com.invalid> writes:
Mon, 30 Nov 2009 04:55:29 +0000, dsimcha wrote:

 == Quote from retard (re tard.com.invalid)'s article
 Hi
 after using D1 and Tango for couple of years we decided to experiment
 with D2 and Phobos in a small scale project. For some reason the mostly
 flat package hierarchy seemed rather confusing. For instance, it took
 two of us 15 minutes to build a program that reads a line from user,
 converts the string to a natural number, adds one, and finally prints
 it to the screen.

While I agree that the docs for Phobos should be improved after the language stabilizes, I honestly don't think 15 minutes is too bad if you're completely unfamiliar with the API. Using Java's file I/O API, for example, practically requires a Ph.D. in object-oriented design. It's just a fact of life that every API has its quirks that take time to learn, and anything that's not what you're used to is going to seem quirky at first.

Well, they have been teaching the Java i/o stuff to first year students for a while now. I completely agree that it's a bit too complicated for novices, but it's not the only bad thing: public static void main(String[] args) { System.out.println("Hello world!"); } Wtf. They used to learn Scheme: (print "Hello World") I guess the PhD requirement is a bit exaggerating. Of course you do need to learn some basic concepts first. OTOH I know a handful of C programmers who just don't get why their (unbuffered) i/o routines always perform badly, and use libraries instead.
Nov 29 2009
parent "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:hevo45$2to1$2 digitalmars.com...
 Mon, 30 Nov 2009 04:55:29 +0000, dsimcha wrote:

 Well, they have been teaching the Java i/o stuff to first year students
 for a while now. I completely agree that it's a bit too complicated for
 novices, but it's not the only bad thing:

 public static void main(String[] args)
 { System.out.println("Hello world!"); }

Correction: class Main { public static void main(String[] args) { System.out.println("Hello world!"); } } (Or something like that anyway, been forever since I touched Java.)
 Wtf. They used to learn Scheme:

 (print "Hello World")

 I guess the PhD requirement is a bit exaggerating. Of course you do need
 to learn some basic concepts first. OTOH I know a handful of C
 programmers who just don't get why their (unbuffered) i/o routines always
 perform badly, and use libraries instead. 

Nov 30 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Lars T. Kyllingstad, el 30 de noviembre a las 12:16 me escribiste:
 Ary Borenszweig wrote:
KennyTM~ wrote:
By
far the two most important pieces of I/O functionality I need are:

1.  Read a text file line-by-line.

foreach (line; new Lines!(char) (new File ("foobar.txt"))) Cout (line).newline; }

yuck.

Yuck?? I find that code very elegant. How would you like it to be?

I wouldn't go as far as saying "yuck" to the above, but I like the Phobos way better: foreach (line; File("foobar.txt").byLine) { ... }

I think you need a few more imports in Tango too. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Come on, now, I hear you're feeling down. Well I can ease your pain Get you on your feet again.
Nov 30 2009