This change would affect file related programming style in Ruby too much, I'm afraid. Our familiar style using "open" will no longer be
Instead of making this change, how about the idea of that Kernel#open calls some callback method (e.g. "to_open") if it's available for the first argument?
def open(arg, *rest)
if defined? arg.to_open
return arg.to_open(*rest)
end
...
end
By this change, Kernel#open can handle URL, Pathname, etc.
--matz.
to_open is good idea to preserve the style for open. But it cannot treat other kind of polymorphic operation: mkdir, rename, delete, etc. Since introducing to_mkdir, to_rename, to_delete, etc is ugly, the conversion and the actual operations may be splitted:
def open(arg, *rest)
if defined? arg.to_filename
return arg.to_filename.open(*rest)
end
...
end def Dir.mkdir(arg, *rest)
if defined? arg.to_filename
return arg.to_filename.mkdir(*rest)
end
...
end def File.read(arg, *rest)
if defined? arg.to_filename
return arg.to_filename.read(*rest)
end
...
end ... class String; def to_filename() Pathname.new(self) end end
class Pathname; def to_filename() self end end
class URI::HTTP; def to_filename() self end end
class URI::FTP; def to_filename() self end end
This makes possible to Dir.mkdir(uri), File.read(uri). But it may be confusing because URI::HTTP and URI::FTP is not implemented by Dir or File.
So I don't want to encourage polymorphic Dir.mkdir, etc. I want to encourage file operations in OOP style over class methods on File and Dir.
The encouragement means that the notation in OOP style should be shorter than current notation in most cases. Unfortunately, without %p literal, Dir.xxx and File.xxx are the shortest notation:
%p'...'.mkdir
Dir.mkdir('...')
'...'.to_open.mkdir
'...'.to_filename.mkdir %p'...'.read
File.read('...')
'...'.to_open.read
'...'.to_filename.read
So, %p'...' is needed to encourage the OOP style.
This is why I proposed %p literal, instead of extending open-uri to treat File.read etc.
--akr
I believe file system operation has some kind of procedural mental model, so that most of use prefer:
mkdir path
to
path.mkdir
This is the reason why I'm not attracted by the idea of pathname literals. I prefer the idea of VFS (Virtual File System) module with proper set of callback methods, for example:
module VFS
def mkdir(path, *args)
if defined? path.create_directory
return path.create_directory(*args)
end
process "mkdir" with string path.
end
end
to keep procedural mental model.
-- matz.
This change would affect file related programming style in Ruby too much, I'm afraid. Our familiar style using "open" will no longer be
Instead of making this change, how about the idea of that Kernel#open calls some callback method (e.g. "to_open") if it's available for the first argument?
By this change, Kernel#open can handle URL, Pathname, etc.
--matz.
to_open is good idea to preserve the style for open. But it cannot treat other kind of polymorphic operation: mkdir, rename, delete, etc. Since introducing to_mkdir, to_rename, to_delete, etc is ugly, the conversion and the actual operations may be splitted:
This makes possible to Dir.mkdir(uri), File.read(uri). But it may be confusing because URI::HTTP and URI::FTP is not implemented by Dir or File.
So I don't want to encourage polymorphic Dir.mkdir, etc. I want to encourage file operations in OOP style over class methods on File and Dir.
The encouragement means that the notation in OOP style should be shorter than current notation in most cases. Unfortunately, without %p literal, Dir.xxx and File.xxx are the shortest notation:
So, %p'...' is needed to encourage the OOP style.
This is why I proposed %p literal, instead of extending open-uri to treat File.read etc.
--akr
I believe file system operation has some kind of procedural mental model, so that most of use prefer:
to
This is the reason why I'm not attracted by the idea of pathname literals. I prefer the idea of VFS (Virtual File System) module with proper set of callback methods, for example:
to keep procedural mental model.
-- matz.