Ruby-dev summary 19380-19436

Masayoshi_TAKAHASHI · 27 January 2003 23:41

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

Chalmers · 27 January 2003 23:49

[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…

use RDoc

use camelCase for variable names and method names

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

Regards,

Robert Feldt

···

On Tue, 28 Jan 2003, TAKAHASHI Masayoshi wrote:

David_Alan_Black1 · 27 January 2003 23:58

Hi –

···

On Tue, 28 Jan 2003, TAKAHASHI Masayoshi wrote:

use camelCase for variable names and method names

Please tell me this was a typo…

David

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

Gavin_Sinclair · 27 January 2003 23:59

[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:

Daniel_Carrera · 28 January 2003 00:21

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

Martin_DeMello1 · 28 January 2003 00:39

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:

You really shouldn’t cast a float to a rational, so it can’t return
Rational.
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)
If you must convert float to rational, it should be explicit.

martin

···

TAKAHASHI Masayoshi maki@rubycolor.org wrote:

Chalmers · 27 January 2003 23:51

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…

U.Nakamura1 · 27 January 2003 23:56

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…

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

Daniel_Carrera · 28 January 2003 00:11

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…

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

Gavin_Sinclair · 28 January 2003 00:45

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.

Masayoshi_TAKAHASHI · 28 January 2003 15:26

use two-space indentation, no TABs

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

use camelCase for variable names and method names

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

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:

Dmitri_Colebatch · 28 January 2003 00:00

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…

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:

Daniel_Carrera · 28 January 2003 00:05

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…

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

David_Alan_Black1 · 28 January 2003 00:10

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…

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

Topic		Replies	Views
Ruby Weekly News 13th - 19th December 2004 ruby-talk	0	81	22 December 2004
[Ann] Reg 0.4.5 ruby-talk	1	105	17 May 2005
A Ruby WishList ruby-talk	0	80	21 April 2004
[ANN] regextest 0.1.5 Released! ruby-talk	8	256	5 September 2016
MetaRegexp: experimental extensions to Regexp (requesting feedback) ruby-talk	3	115	3 October 2010

Ruby-dev summary 19380-19436

Regards,

Related Topics