Ruby-dev summary 19380-19436

ruby-talk
1

Hello all,

This is a summary for last week on the ruby-dev mailing list.

[ruby-dev:19383] detecting features in extconf.rb

Nobu Nakada indicated pitfalls to write extconf.rb.

  • respond_to? should not be used. It may not work
    for cross compilation.
  • egrep_cpp always fails without egrep.
  • library names are not identical in any platform.
    They can vary by configuration.

[ruby-dev:19410] match of [\001]

WATANABE Tetsuya pointed out that /[\001]/ does not
match strings including “\001” in Ruby 1.8.0 when
$KCODE is not ‘n’. Matz replied that numerical notation
of Ruby’s Regexp matched a part of multibyte characters.
In future, this specification will be deprecated,
though it’s feature for now.

[ruby-dev:19387] standard ruby lib coding convension

NaHi asked to Matz for coding convension for standard
ruby library. Matz recommended to:

  • use two-space indentation, no TABs
  • use RDoc
  • use camelCase for variable names and method names
  • use camelCase for class names and module names
  • use upper case separated by ‘_’ for constants

[ruby-dev:19406] [Oniguruma] Version 1.6

Kosako released new version of Oniguruma (yet another
Regexp library for Ruby).

* supported Win32(VC++)
* fixed bugs of POSIX API
* improved speed

[ruby-dev:19423] Numeric#quo

Matz announced that he implemented quotient method
Numric#quo. This method returns accurate value
as much as possible, using class Rational.

ex. 3.quo(2) => 3/2 (Rational)

There are some issues remained.

  • Is the method name ‘quo’ appropriate?
  • Should we make Rational into standard?
  • Does int.quo(float) and rational.quo(float) return
    Rational or Float?

[ruby-dev:19430] HAVE_* macros

Akinori MUSHA proposed to add symbols to ruby.h and intern.h,
which represent version depending features, not to need
detecting them in each extconf.rb. Matz agreed the idea
itself, but disliked some names he showed.

#define HAVE_RB_DEFINE_ALLOC_FUNC
#define HAVE_RB_CVAR_SET_WITH_WARN

#define HAVE_1ARY_NORETURN

or

#define RUBY_NORETURN_STYLE 0 /* prototype NORETURN; /
#define RUBY_NORETURN_STYLE 1 / NORETURN(prototype); */

or

#define RUBY_NORETURN_STYLE_xxxx

Regards,

TAKAHASHI ‘Maki’ Masayoshi E-mail: maki@rubycolor.org

2

[ruby-dev:19387] standard ruby lib coding convension

NaHi asked to Matz for coding convension for standard
ruby library. Matz recommended to:

  • use two-space indentation, no TABs

Yes, yes, yes!!! I’ve feldt I’ve been right, all the time… :slight_smile:

  • use RDoc
  • use camelCase for variable names and method names

This surprised me. Method names in camelCase? I must have been away too
long… :wink:

Regards,

Robert Feldt

···

On Tue, 28 Jan 2003, TAKAHASHI Masayoshi wrote:

3

Hi –

···

On Tue, 28 Jan 2003, TAKAHASHI Masayoshi wrote:

  • use camelCase for variable names and method names

Please tell me this was a typo… :slight_smile:

David

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

4

[ruby-dev:19387] standard ruby lib coding convension

NaHi asked to Matz for coding convension for standard
ruby library. Matz recommended to:

  • use two-space indentation, no TABs
  • use RDoc
  • use camelCase for variable names and method names
  • use camelCase for class names and module names
  • use upper case separated by ‘_’ for constants

The standard library at the moment uses CamelCase for classes and
modules and this_kind_of_case for methods and variables. Is that
about to change?

[ruby-dev:19423] Numeric#quo

Matz announced that he implemented quotient method
Numric#quo. This method returns accurate value
as much as possible, using class Rational.

ex. 3.quo(2) => 3/2 (Rational)

There are some issues remained.

  • Is the method name ‘quo’ appropriate?

Good enough for me. 3.over(2) sounds natural but might be a bit
colloquial.

  • Should we make Rational into standard?

That would be nice, barring potential portability issues.

  • Does int.quo(float) and rational.quo(float) return
    Rational or Float?

These should be equivalent to Rational(a, b). I don’t know how that
behaves, but hopefully it’s well thought out.

Gavin

···

On Tuesday, January 28, 2003, 10:41:36 AM, TAKAHASHI wrote:

5
  • use two-space indentation, no TABs

Is that a rigid rule. I like 4 spaces. I can do without TABs, but I
really want to indent my code.

There are some issues remained.

  • Is the method name ‘quo’ appropriate?

I can’t imagine what “quo” would stand for. How about 3.div(2) or
3.frac(2) ?

  • Should we make Rational into standard?

Sure.

  • Does int.quo(float) and rational.quo(float) return
    Rational or Float?

Any conversion from float to rational will have some errors, and I think
that people would expect Rational to be exact.

I would suggest to return Float, because at least people expect to see
some round-off issues there.

···

On Tue, Jan 28, 2003 at 08:41:36AM +0900, TAKAHASHI Masayoshi wrote:

–
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

6
  • Is the method name ‘quo’ appropriate?

IMO, no. It reads very badly. I’d like a.over(b), though as Gavin said,
it’s a bit colloquial.

  • Should we make Rational into standard?

My knee-jerk reaction is ‘yes’, but I’d like to hear some of the
'against’s first. Also, I realise that I’ve never actually had reason to
use Rational.

  • Does int.quo(float) and rational.quo(float) return
    Rational or Float?

Somewhat unorthodox, but I’d raise a “quo called with non-Rational”
exception, for the following reasons:

  1. You really shouldn’t cast a float to a rational, so it can’t return
    Rational.
  2. If you’re using quo rather than /, you probably have a good reason
    for wanting the exactness of a Rational, so returning a Float is
    pointless (no pun intended)
  3. If you must convert float to rational, it should be explicit.

martin

···

TAKAHASHI Masayoshi maki@rubycolor.org wrote:

7

Oops, freudian slip there. “feldt” should be “felt”…

I will stop wasting bandwidth right now.

/RF

···

On Tue, 28 Jan 2003, Robert Feldt wrote:

  • use two-space indentation, no TABs

Yes, yes, yes!!! I’ve feldt I’ve been right, all the time… :slight_smile:

8

Hello,

In message “Re: ruby-dev summary 19380-19436”

···

on Jan.28,2003 08:49:12, feldt@ce.chalmers.se wrote:

  • use camelCase for variable names and method names

This surprised me. Method names in camelCase? I must have been away too
long… :wink:

It’s Takahasi-san’s mistake.
Matz said “shouldn’t use camelCase for variable names and method names.”

Regards,

U.Nakamura usa@osb.att.ne.jp

9

He he, yes it’s a typo.

···

On Tue, Jan 28, 2003 at 08:58:18AM +0900, dblack@candle.superlink.net wrote:

Hi –

On Tue, 28 Jan 2003, TAKAHASHI Masayoshi wrote:

  • use camelCase for variable names and method names

Please tell me this was a typo… :slight_smile:

–
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

10

Only if you’re writing code for the standard library! That’s the
context of the original post.

Gavin

···

On Tuesday, January 28, 2003, 11:21:29 AM, Daniel wrote:

  • use two-space indentation, no TABs

Is that a rigid rule. I like 4 spaces. I can do without TABs, but I
really want to indent my code.

11
  • use two-space indentation, no TABs

Yes, yes, yes!!! I’ve feldt I’ve been right, all the time… :slight_smile:

:slight_smile:

  • use camelCase for variable names and method names

This surprised me. Method names in camelCase? I must have been away too
long… :wink:

Oops, I’m sorry so much. It’s my fault. Usa-san’s comment in
[ruby-talk:62894] is correct.
When I was deleting errors in the draft of my mail,
I deleted too many words X-<

Regards,

TAKAHASHI ‘Maki’ Masayoshi E-mail: maki@rubycolor.org

···

Robert Feldt feldt@ce.chalmers.se wrote:

12

Question from a newbie here…

In message “Re: ruby-dev summary 19380-19436”

  • use camelCase for variable names and method names

This surprised me. Method names in camelCase? I must have been away too
long… :wink:

It’s Takahasi-san’s mistake.
Matz said “shouldn’t use camelCase for variable names and method names.”

so the preferred convention is to use underscores for my_method instead of
myMethod ?

cheers
dim

··· 
on Jan.28,2003 08:49:12, <feldt@ce.chalmers.se> wrote:
13

Good. I don’t like camelCase.

···

On Tue, Jan 28, 2003 at 08:56:26AM +0900, U.Nakamura wrote:

This surprised me. Method names in camelCase? I must have been away too
long… :wink:

It’s Takahasi-san’s mistake.
Matz said “shouldn’t use camelCase for variable names and method names.”

–
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

14

Hi –

···

On Tue, 28 Jan 2003, Dmitri Colebatch wrote:

Question from a newbie here…

In message “Re: ruby-dev summary 19380-19436”
on Jan.28,2003 08:49:12, feldt@ce.chalmers.se wrote:

  • use camelCase for variable names and method names

This surprised me. Method names in camelCase? I must have been away too
long… :wink:

It’s Takahasi-san’s mistake.
Matz said “shouldn’t use camelCase for variable names and method names.”

so the preferred convention is to use underscores for my_method instead of
myMethod ?

Yes, and similarly for variable names.

David

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav