Re: Some potential RCRs [Comments Summarized]

"Bob Alexander" <[e-mail]> wrote in message
news:019801c1cb86$63a9e7a0$0f70ea0c@C322162A...
>
> ------------------
> A format specification in "printf"-type formats that inserts the result of
> applying "inspect" to the argument (similar to how %s inserts
argument.to_s)
>
> The only comment was that the %r specification letter I used in my example
> might not be the best choice. I agree. I'll try to propose the perfect
> letter in the RCR, after extensive research. Ideas?

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.

> ------------------
> Dir methods that produce directory entries should never produce "." and
> "..".
>
> There were some strenuous objections to this, and some liked it. Since few
> can deny the inconvenience of having to filter out the "self" and "parent"
> entries ('.' and '..') in practically all applications except a simulated
> "ls -a" command, I'll modify the original suggestion to providing new
> methods that do not produce the special names that do not actually
represent
> directory "contents" per se:
>
>     Dir::contents(path)
>     Dir::each_name(path)
>
> (Suggestions for better method names are welcome.)
>
> This change removes the possibility of breaking existing code, too.
>
> Some responders brought up the possibility of having a sort of "abstract
> path" object, but that's a topic worthy of a separate thread.

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.

> ------------------
> A "message" parameter for "abort".
>
> Hey -- even Matz liked it! The only instantly pre-approved RCR in this
> batch.  :-)

How is Abort different from Exit?  Exit already has an optional parameter,
why not make another optional parameter for Exit that accepts a message
string rather than adding a parameter to a function which currently takes no
parameter, and in my opinion isn't supposed to?

Abort, Exit with status or Raise an exception.

Exit [Number | String] seems more consistent to me than Exit [Number] and
Abort [String].

    Sean