[#10193] String.ord — David Flanagan <david@...>

Hi,

41 messages 2007/02/05
[#10197] Re: String.ord — Yukihiro Matsumoto <matz@...> 2007/02/06

Hi,

[#10198] Re: String.ord — David Flanagan <david@...> 2007/02/06

Yukihiro Matsumoto wrote:

[#10199] Re: String.ord — Daniel Berger <djberg96@...> 2007/02/06

David Flanagan wrote:

[#10200] Re: String.ord — David Flanagan <david@...> 2007/02/06

Daniel Berger wrote:

[#10208] Re: String.ord — "Nikolai Weibull" <now@...> 2007/02/06

On 2/6/07, David Flanagan <david@davidflanagan.com> wrote:

[#10213] Re: String.ord — David Flanagan <david@...> 2007/02/06

Nikolai Weibull wrote:

[#10215] Re: String.ord — "Nikolai Weibull" <now@...> 2007/02/06

On 2/6/07, David Flanagan <david@davidflanagan.com> wrote:

[#10216] Re: String.ord — David Flanagan <david@...> 2007/02/07

Nikolai Weibull wrote:

[#10288] Socket library should support abstract unix sockets — <noreply@...>

Bugs item #8597, was opened at 2007-02-13 16:10

12 messages 2007/02/13

[#10321] File.basename fails on Windows root paths — <noreply@...>

Bugs item #8676, was opened at 2007-02-15 10:09

11 messages 2007/02/15

[#10323] Trouble with xmlrpc — James Edward Gray II <james@...>

Some of the Ruby code used by TextMate makes use of xmlrpc/

31 messages 2007/02/15
[#10324] Re: Trouble with xmlrpc — "Berger, Daniel" <Daniel.Berger@...> 2007/02/15

> -----Original Message-----

[#10326] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/15

On Feb 15, 2007, at 1:29 PM, Berger, Daniel wrote:

[#10342] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/16

While I am complaining about xmlrpc, we have another issue. It's

[#10343] Re: Trouble with xmlrpc — Alex Young <alex@...> 2007/02/16

James Edward Gray II wrote:

[#10344] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/16

On Feb 16, 2007, at 12:08 PM, Alex Young wrote:

Re: [ ruby-Bugs-8537 ] Module:constants returns unexpected result

From: Sam Roberts <sroberts@...>
Date: 2007-02-09 21:25:58 UTC
List: ruby-core #10264
On Sat, Feb 10, 2007 at 02:23:55AM +0900, noreply@rubyforge.org wrote:
> Initial Comment:
> Module:constants returns unexpected results; e.g.
> 
>       module A
>          C = 1
>          module B
>             p A::B::constants
>          end
>       end
> 
> returns an empty array. This does not fit the documentation:
> 
>       call-seq:
>          mod.constants    => array
> 
>       Returns an array of the names of the constants accessible in
>       <i>mod</i>. This includes the names of constants in any included
>       modules (example at start of section).
> 
> In module A::B the constants A, B, and C are accessible and therefore should be included in the result!?

Accessible, yes.

Accessible **in** A::B? Try:

  p A::B::C

and you will find that C is not in module A::B

Think about it. All the standard library classes, String, Time, etc. are
constants, and they can be "accessed", did you want every single
"accessible" class to be listed in A::B.constants? That would be quite a
large list....

Sam


In This Thread

Prev Next