Re: Some potential RCRs [Comments Summarized]

"Bob Alexander" <[e-mail]> wrote in message
news:01bb01c1cbdd$1c1a6f70$0f70ea0c@C322162A...
> "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?

Being able to filter out, or filter in, files by property is also very
useful.  My suggestion:

1)  Doesn't add a new function to the language, big bonus
2)  Is compatible with existing code out there
3)  Adds much more functionality than merely dealing with child directory
entries at the same low price as 1 and 2.

I don't see the advantage to having a whole new function which doesn't do
anything except solve a single issue, when you could just extend the
existing function in a backwards compatible way and which also comes with
higher functionality.

Sometimes new functions are called for.  But just to filter out '.' and
'..'?  Seems wasteful and a missed opportunity to add some useful stuff
besides solving the one problem.

    Sean