Re: Some potential RCRs [Comments Summarized]

"Sean O'Dell" wrote:
> Actually, I suggested a format specification for output of object
> information, with %@ being the format specifier.  There could be %@i for
> object.inspect, %@s for object.to_s, etc.  The argument to printf for each
> specification would be just the object.

That's pretty much how it works already. "%s" means "apply to_s", "%d" and
"%i" mean "apply to_i". I imagine the others work similarly. But, there
currently isn't one that means "apply inspect". I think it's better to stick
with the current style of using single letters but just designate a letter
that isn't currently used for anything . It should also be "intuitive" --
now that's a challenge! My first choice would be "i" since Ruby programmers
are familiar with "inspect", but that one's already used (a Ruby overload to
the C printf spec). Uppercase %I, maybe? Or %p, to be reminiscent of our "p"
method (not to mention it's the center letter of insPect  :-)?


> > ------------------
> > Dir methods that produce directory entries should never produce "." and
> > "..".
> > ...

> Why not add an optional parameter to Dir for modifying the content
returned,
> rather than heaping more functions into the language?  It would allow for
> DIR_CHILDREN flag (which would eliminate '.' and '..') as well as allow
> other flags like DIR_DIRECTORIES, DIR_FILES, DIR_BLOCKDEV, DIR_SYMLINKS,
or
> NO_DIRECTORIES, NO_FILES, NO_BLOCKDEV, NO_SYMLINKS, etc.

Before deciding on the different-method-name approach, I thought of the
extra-parameter-to existing-method approach. But I think I still slightly
prefer my suggestion because:

  - it's simple.
  - the "children" filter is a very common need -- enough so to warrant
special handling.
  - the other filters you mention are needed much less often, so I don't
mind writing the bit of extra code to filter it myself.
  - some directory entry methods produce a list, and some iterate. I would
like to see versions of both that produce children only.

I do, however, like your choice of the word "children", which escaped me
when I came up with suggested names. How about

    Dir.children => array of child names
    Dir.each_child iterates over child names

Those names are intuitive and easy to remember.

(I suspect that if we have these new methods, the existing "entries" and
"foreach" will be rarely used.)

So, my inclination is to leave my soon-to-be RCR pretty much as it is. Your
ideas for special filtering methods are interesting, though. Why not submit
a separate RCR?


Bob