Is there any object-oriented File class in ruby?

Ruby
21

On Feb 20, 12:52 am, Christopher D. [email protected] wrote:

Which also seems to be a string parsing function with no necessary OO
abstraction. Handling a variety of path separators is orthogonal to
whether there is OO abstraction going on.

Yes, you are right and internally the implemention of the java method
will need to parse the string somehow.
However, an important difference with ruby File class and the java
File class is that the java class provides a cohesive unit of instance
methods that encapsulates a file path, without having to provide a
string as parameter to every method.
Since the ruby class method “File.basename(filename)” is nothing but a
string parsing method it does IMHO not provide much useful value over
instead having a class method such as
“String.getStringPartAfterLastSlash(anyStringIncludingSomeSlash)”
or
“String.getStringPartAfterLastOccuranceOfSpecifiedCharacter(anyString,
someCharacter)”.

Anyway, I have found what I was looking for in another reponse in this
thread:

On Feb 19, 11:40 pm, tom_33 [email protected] wrote:

Now my question is what have I been missing here ?
I mean, is there any other much better File class somewhere in the
Ruby core that is more pure OO …

On Feb 20, 12:37 am, Gary W. [email protected] wrote:

On Feb 19, 2008, at 5:45 PM, tom_33 wrote:
There is also Pathname, a class for manipulating file path strings
and looking up file properties.

Yes, that was indeed the kind of class I was looking for.
Obviously Ruby supports a procedural invocation style of using class
methods on the File class (the same way you would do it with non-oo-
language such as C, i.e. providing the same parameters over and over
again since there is no object that can encapsulate it in a
constructor call).

For example, if you would want to implement a methods that renames
files that are old and big (for some reason) then you would do this
kind of stuff with the File class:

if File.size(file_name) > someSizeLimit and File.mtime(file_name) <
someTimeLimit then
… do some string manipulation to extract the filename part from the
full path
… and also extract the directory part …
new_name = “big_old_file_” + fileNamePart
new_nameWithFullPath = directoryPart + “/” + new_name
File.rename(file_name, new_nameWithFullPath)
end

But with the much better Pathname class you can get an object with
instance methods:

path = Pathname.new(file_name)
if path.size() > someSizeLimit and path.mtime() < someTimeLimit then
directory = path.parent
fileNamePart = path.basename
new_name = “big_old_file_” + fileNamePart

below file separator concatenation seems to be automatically

included if needed:
newPath = directory + new_name
path.rename(newPath)
end

There are two things that are better with the above code that uses
Pathname instead of File:
(1) You do not have to keep sending the same path string to the
methods but in can be encapsulated and memorized by the Pathname
instance.
(2) You do not need to extract (and concatenate with separators) the
directory part and the filename part through low level string parsing.

Lastly, I just want to complain a little bit about the documentation
of the File class, and hope that someone with write access to the
following page:
http://www.ruby-doc.org/core/classes/File.html
will update it with a reference to the Pathname class, from the the
description section in the beginning.
Without such a reference, it is likely that other people will use the
File class methods, without finding the Pathname class and its nice
instance methods.
Actually, I do not only think it should be mentioned, but it should be
encouraged to use them instead of the File class methods.

22

On Feb 20, 2008, at 1:29 PM, tom_33 wrote:

However, an important difference with ruby File class and the java
File class is that the java class provides a cohesive unit of instance
methods that encapsulates a file path, without having to provide a
string as parameter to every method.

Path name parsing aside – which is really a small part of what File
does – here are some comments.

To open and read each line in a file, do this:

File.open(filename, mode) do |f|
f.each {|line| #do something with the line}
end

Notice that the file is opened and a block yielding the context of the
open file is used thereafter for file manipulation. There are a bunch
of filesystem interrogation methods that are, by their nature, better
handled by passing strings. Why? Because often you don’t want to open
a file just to find out when it was modified or what its basename is.
That’s why there are so many class methods (or, if you prefer, “static
functions”).

Encapsulation is about keeping your data in a safe place where the
implementation of the data store is abstracted. Access is through
methods that don’t change. It’s conceivable that you could create a
class to wrap the File functions like:

class FileTools
def initialize(file_name)
@file_name = file_name
end

def basename
File.basename(@file_name)
end

def atime
File.atime(@file_name)
end

etc.

end

Then you would need to do this in your code:

f = FileTools.new(‘my.file’)
basename = f.basename
last_accessed = f.atime

I don’t typically use a ton of these methods, so specifying the string
each time isn’t a huge burden. Creating a new object just so you can
interrogate the filesystem seems like overkill – it’s unlikely the
interface to the filesystem will change any time soon.

Just my $.02