Re: Some potential RCRs

"Yukihiro Matsumoto" <[e-mail]> wrote in message
news:[e-mail]...
> Hi,
>
> In message "Some potential RCRs"
>     on 02/03/13, "Bob Alexander" <[e-mail]> writes:
> |------------------
> |"p" method should return its last argument, unconverted.
>
> Hmm.  I'd like to hear others' opinion.

Seems like p should return the length of the output.  Having it return the
last argument is neat, but not "what I would expect."

> |------------------
> |A format specification in "printf"-type formats that inserts the result
of applying "inspect" to the
> |argument.
> |
> |E.g. "Value of x: %r\n" % x.
>
> Sounds good, but I'm not sure whether %r is good or not.  Maybe it's
> too ambiguous.  We should be quite conservative about non traditional
> (and perhaps non intuitive) mnemonic.

Why not a whole new class of % statements, like %@i (for inspect) %@s (for
to_s).

> |------------------
> |A "println" method.
> |
> |Would work just like "print" but would tack on a newline. Yeah, I know it
doesn't seem much different than
> |just coding "\n" as a final parameter, but I find "println" more pleasing
and more self-describing
>
> How much omitting the last "\n" might buy you?

I don't use println, but I kinda see his point.  I can see the usefulness in
having the routine name telling you distinctly that there WILL be a newline
character printed here, but at the same time, every place I've seen println
it has annoyed me and I've changed it.

> |------------------
> |Dir methods that produce directory entries should never produce "." and
"..".
> |I see no use in producing "." and "..", and it is a nuisance having to
explicitly filter them out (usually
> |after forgetting to do it and getting a program error!) Also, seems a tad
non-portable.
>
> I'd like to hear others' opinion about this issue too.

'.' and '..' are real entries in the directory and are part of the nature of
that file system.  chmod is a tad non-portable, too.  It depends what the
philosophy is.  Is Ruby supposed to provide a virtual machine?

> |------------------
> |The built-in Mutex object should be nestable.
> |
> |Acquiring a mutex in nested contexts in the same thread should not cause
deadlock. It doesn't seem
> |appropriate for a language at Ruby's level to have a non-nestable Mutex,
and it is a pothole for program
> |errors.
>
> I will take time to investigate it later (I'm not a thread expert).
> Maybe one of you help me with better implementation.

I think this definitely needs to change, if that's how it works, or at least
it should be an option when creating the mutex.  The same context should be
able to call the same mutex recursively and obtain the lock each time.  Each
time increasing the mutex' lock count, each release decrementing the mutex
lock count.

Often, multiple routines called in the same context will need to lock the
same mutex to ensure a resource is safely locked.  Since the same context
isn't likely to step on itself because of a multithreading issue

> |------------------
> |A "message" parameter for "abort".
> |
> |Coding
> |
> |    abort("the program did something bad")
> |
> |would print the message before terminating.
>
> Sounds good.  It will be in 1.7 soon.

Why not just enhance the exit call to accept a second optional string
parameter as an exit message?  I like abort being just a quick and dirty
exit.  On the other hand, exit is like abort, but with a little more detail
given (the exit status), so if you add more detail to something, why not
exit instead of abort?

    Sean