From: Massimiliano Mirra <list@...>
Date: 2002-01-13T22:46:56+09:00
Subject: Re: FileHandle (was: Re: Dir.entries have no home)


On Sun, Jan 13, 2002 at 01:47:23PM +0900, Ron Jeffries wrote:
> >  def method_missing(method_id, *args, &block)
> >    if @info.keys.include? method_id
> if@ location was a hash with keys old/new. Is that right?
> If that's right, 

(Which it is.)

> I might have thought that defining the methods would
> be more clear, and, not that it's important, more efficient. Am I
> missing the meaning, or not understanding the goodness of this
> approach?

Personal preference.  Having to just add one item in a hash rather
than a whole method definition makes the screen less crowded with
same-functionality snippets and lets me insert new information by just
inserting a new key in the same place (the hash), instead of
redefining three-line screen-wandering method definitions.  This might
make the program slightly less efficient but will make me quite a bit
more efficient.

And, if I had been a good boy and not so parsimonious of comments, it
might have made you more efficient as well. :-)

On Sun, Jan 13, 2002 at 02:07:25PM +0900, Ron Jeffries wrote:
> A couple more things, then I really am going to bed. Seems like that
> last method could be written as
> >  def path=(new)
> >    @info[:path][:new]     = new
> >    @info[:name][:new]     = File.basename(new)
> >    @info[:location][:new] = File.dirname(new))
> >  end

You're right.  Thank you.

>  Also, it seems that these methods are trying to maintain a
> consistency relationship between name, path, and location. 
> Why not instead just let path be virtual and maintain the other two,
> something like this:

> > def path
> >    File.join(@info[:location][:new], @info[:name][:new])
> > end
> 
> Wouldn't something like that be simpler and less prone to error?

You're right again.

And that also allows me to get rid of location and name method, though
I guess you'll hate me for that.

> Then, finally, instead of the hash, I might prefer to set up an object
> of class, say, FileInfo with instance variables and accessors
> location, path, name and so on, and to have two instances of FileInfo
> in FileHandle, @newInfo and @oldInfo, so we could write
> 
> def name=(new)
>   @newInfo.name=new
> end
> 
> and the like. Maybe there's some complex manipulation of the new and
> old that I don't understand yet that would get in the way of doing
> this ...

Not that I remember (I should stop writing programs near bedtime, too
;-) ).  Your form is more readable and two Struct's would make it not
much wordier to initialize than a hash, I'll try it right away.

Thanks!

Massimiliano