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.

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.
>> 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.

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

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?

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.
> 
> 
Something like new BufferedReader(new FileReader("foo.txt"))? It's quite unambiguous.

I'll rather have open as a file-opening function.

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.
>>> 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.
> 
> 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.

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.
>>>> 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.
>> 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.
Not in python you can't. Also, in D, this wouldn't be a problem, since if it is ambiguous, the compiler will tell you so.

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.
>>
>>
> Something like new BufferedReader(new FileReader("foo.txt"))? It's quite
> 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

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

Rainer Deyke wrote:
> 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.
>>>
>>>
>> Something like new BufferedReader(new FileReader("foo.txt"))? It's quite
>> 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.
> 
	Note that 'open ("foo.txt", O_RDONLY)' is perfectly valid C code
for opening a file (unbuffered).

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

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