[ruby-dev:15515] Re: fileutils (2)

高橋征義です。結論は最後に。

Minero Aoki <[e-mail]>さん：
> まあ、互換性というか「どうせ 1.7 以降に入るんだから 1.7 以降
> 対応でいいじゃん」または「いまさら 1.6 なんて使えるかぁっ！」
> ということです。

いやいや、amstd/fileutils.rbとの互換性です(ftools.rbもかな？)。

> ついでに ftools と上位互換でも
> あるはずです (File に extend するとそのまま通用する)。

む、しかし引数が違いますよね(verboseとか)。って、そういう意味ではなく？

> でも、メソッド名から言っても cp なら cp(1) のように働いてほしいと
> 思うのではないでしょうか？ (本当は話が逆だけど) この場合に限っては
> Ruby 的であるよりもシェル的であるほうがよいのではないかと思うのです。

うーん、そうでしょうか。
例えば、Dir::mkdirでも、
  mkdir(path [,mode])
となっています。ftoolsのcpやmvでもverboseオプションは後ろですし。

> あるいは、オプションを前じゃなくて後ろに与えた場合 dir の位置は
> 固定になりますけどそれはどうでしょう？ 実装としては、オプションは
> どこでもいい、というのも可能です。

そうですね、前か後ろだったら、(上のDir::mkdirのように)後ろの方が
好きです。さらに、引数の位置が決まっていれば安心です。
# キーワード引数があればまた違うんでしょうけどね……。

> >   def newest?( *args )
> >     (new,*fnames), (verbose,) = fu_parseargs( args, 1..INF, :verbose )
(略)
> ちょっとトリッキーですかね。

理想を言えば、メソッドのdefの部分を見れば、そのメソッドの引数の
使い方がなんとなく伝わるのがベストだと思います。この場合、*args
しかないのであんまりうれしくないのです。あくまで理想ですけど。

> たとえば
> 
>     rb = %w(
>         mail.rb loader.rb field.rb ....
>     )
>     rb2 = %w(
>         parsemail.rb
>     )
> 
> としておいて
> 
>     cp rb, rb2, mkdir_p(site_ruby + '/tmail')
> 
> ってのがとっても楽なんですよー。

これってたとえば、ていねいにやるなら、

   tmail_dir = site_ruby + '/tmail'
   mkdir_p(tmail_dir)
   cp(rb,  tmail_dir)
   cp(rb2, tmail_dir)

とやれば、やってる内容が明快で、さほど回りくどくもないのでいいと
思うんですけど。というか、
   cp(rb + rb2,  mkdir_p(site_ruby + '/tmail'))
とか
   (rb+rb2).each{|file| cp(file, mkdir_p(site_ruby + '/tmail'))}
じゃ駄目なんでしょうか？

それと、これも気になったのですが、なんか配列とそうでないものとを
ごっちゃに(できるように)してません？  ここはやっぱり、
    cp( src, dst ) # src はString
とするか、
    cp( src, dst ) # srcは String または Array
とするのがすっきりしていいと思います(後者はいらないかも)。
# あ、オプションは省略してます。

> each でまわすとするとこれは
> 
>     (rb + rb2).flatten.each do |fname|
>       cp fname, mkdir_p(site_ruby + '/tmail')
>     end
> 
> となって面倒です。

rbとrb2が、配列なのか要素なのかがわかっていれば flatten する
必要はないですよね。で、この場合はそれが分かっているべきなん
じゃないでしょうか。

> また本当にコピーだけでいいなら copy_file(a,b) というメソッドも
> あります。同様なものに remove_file(n) remove_dir(n) も。

どこまでのメソッドが必要か、というのは考えなければいけないですね。

> そういうことなら
> 
>     include FileUtils::Verbose
> 
> で全部 verbose になります。クラスに include してインスタンス化
> しても使えます。あ、private だからだめなのか。それなら public に
> しましょう。

クラス(クラスメソッド)の振舞いを変えるのにincludeを使うのは
面白そうだし便利そうなのですが、「凝りすぎ？」という不安も
若干あるのでした。

> また、インスタンス化できるようにすること自体は特に問題ないですけど、
> include する方法もやはり欲しいです。やっぱ cp ならいきなり cp と
> 書きたいので。(あくまで個人的欲求として、です)

includeというか、インスタンスを作らずにcpしたい、ということですね。
これは私も便利(あるいは必要)かも？  とは思います。
やっぱ後ろにオプション、というのが無難でしょうかね。

> >    fu.verbose = true
> >    fu.noop = true
> 
> このタイプは前に話が出たときにどなたかから否定的な意見が出たので
> 避けました。たとえば preserve を例にとると、cp や cp_r はいいけど
> mv や ln を呼んだとき preserve アトリビュートにどういう意味がある
> のかよくわからないというのが理由です。

うーん、そうですか。
私の気分としては、verboseとnoopはふつーグローバル、forceもたぶん
グローバル、preserveはちょっと微妙、という感じでしょうか。
いちいちverboseを指定しなくちゃいけないのもうざったいかなあと。

> あとそのときは、たけさんから
> 
>     op = FileUtils.operator(:cp, :preserve)
>     op.exec
> 
> みたいな感じに cp するためのインスタンスを作るのはどうか？ という
> 意見もありました。(メソッド名その他は変えてます)

これはこれで、verboseやnoopなら個々に:verboseをつける必要が
出てくるわけで、あまりメリットないかなあ、と。



……というわけで、このメールの結論としては、

 * クラスにするかどうかはともかく、インスタンスを作らないで
   オプションつきでcpしたりmkdirしたりできるようにしたい。
 * オプションは後ろにした方がよさそう。

というところです。

オプションはtrue/falseか、あるいは可変長でしょうか。前者なら、

  def cp(from, to, verbose=false, noop=false)

という感じ、後者なら、

  def cp(from, to, *option) # optionは :verbose とかで指定

みたいな感じとか。後者の方が使いやすい？

高橋征義 (TAKAHASHI Masayoshi)       Email:[e-mail]