[#19075] Request For Removal: No Operator Concatenation — James Gray <james@...>

I'm disappointed that Ruby still supports this goofy syntax:

30 messages 2008/10/01
[#19076] Re: Request For Removal: No Operator Concatenation — "Gregory Brown" <gregory.t.brown@...> 2008/10/01

On Wed, Oct 1, 2008 at 1:58 PM, James Gray <james@grayproductions.net> wrote:

[#19078] Re: Request For Removal: No Operator Concatenation — "Jim Freeze" <jimfreeze@...> 2008/10/01

On Wed, Oct 1, 2008 at 1:08 PM, Gregory Brown <gregory.t.brown@gmail.com> wrote:

[#19080] Re: Request For Removal: No Operator Concatenation — James Gray <james@...> 2008/10/01

On Oct 1, 2008, at 1:15 PM, Jim Freeze wrote:

[#19081] Re: Request For Removal: No Operator Concatenation — "Jim Freeze" <jimfreeze@...> 2008/10/01

On Wed, Oct 1, 2008 at 1:29 PM, James Gray <james@grayproductions.net> wrote:

[#19082] Re: Request For Removal: No Operator Concatenation — James Gray <james@...> 2008/10/01

On Oct 1, 2008, at 1:37 PM, Jim Freeze wrote:

[#19083] Re: Request For Removal: No Operator Concatenation — Eric Hodel <drbrain@...7.net> 2008/10/01

On Oct 1, 2008, at 11:42 AM, James Gray wrote:

[#19084] Re: Request For Removal: No Operator Concatenation — "Gregory Brown" <gregory.t.brown@...> 2008/10/01

On Wed, Oct 1, 2008 at 2:45 PM, Eric Hodel <drbrain@segment7.net> wrote:

[#19087] Re: Request For Removal: No Operator Concatenation — "Jim Freeze" <jimfreeze@...> 2008/10/01

On Wed, Oct 1, 2008 at 2:10 PM, Gregory Brown <gregory.t.brown@gmail.com> wrote:

[#19132] [Feature #615] "with" operator — Lavir the Whiolet <redmine@...>

Feature #615: "with" operator

33 messages 2008/10/05
[#19137] Re: [Feature #615] "with" operator — Nobuyoshi Nakada <nobu@...> 2008/10/06

Hi,

[#19138] Re: [Feature #615] "with" operator — Paul Brannan <pbrannan@...> 2008/10/06

On Mon, Oct 06, 2008 at 10:46:49AM +0900, Nobuyoshi Nakada wrote:

[#19141] Re: [Feature #615] "with" operator — _why <why@...> 2008/10/06

On Mon, Oct 06, 2008 at 10:56:23PM +0900, Paul Brannan wrote:

[#19148] Re: [Feature #615] "with" operator — Trans <transfire@...> 2008/10/06

[#19149] Re: [Feature #615] "with" operator — "Austin Ziegler" <halostatue@...> 2008/10/06

On Mon, Oct 6, 2008 at 3:34 PM, Trans <transfire@gmail.com> wrote:

[#19150] Re: [Feature #615] "with" operator — "David A. Black" <dblack@...> 2008/10/06

Hi --

[#19154] Re: [Feature #615] "with" operator — _why <why@...> 2008/10/07

On Tue, Oct 07, 2008 at 05:47:23AM +0900, David A. Black wrote:

[#19250] default_internal encoding — Dave Thomas <dave@...>

I'm documenting default_internal for the PickAxe, and have a couple of

26 messages 2008/10/09
[#19254] Re: default_internal encoding — "Michael Selig" <michael.selig@...> 2008/10/09

Hi,

[#19255] Re: performance of C function calls in 1.8 vs 1.9 — "Michael Selig" <michael.selig@...> 2008/10/10

On Wed, Oct 8, 2008 at 3:52 PM, Paul Brannan <pbrannan / atdesk.com> wrote:

[#19289] [Bug #633] dl segfaults on x86_64-linux systems — Benjamin Floering <redmine@...>

Bug #633: dl segfaults on x86_64-linux systems

19 messages 2008/10/10

[#19315] [Feature #643] __DIR__ — Thomas Sawyer <redmine@...>

Feature #643: __DIR__

14 messages 2008/10/13

[#19342] [Bug #649] Memory leak in a array assignment? — Henri Suur-Inkeroinen <redmine@...>

Bug #649: Memory leak in a array assignment?

14 messages 2008/10/15

[#19350] Net::HTTP.post_form bug : can't post form to correct uri which contains QueryString(QueryString part are lost) and revise — Klesh <kleshwong@...>

Hi,

10 messages 2008/10/16
[#19352] Re: Net::HTTP.post_form bug : can't post form to correct uri which contains QueryString(QueryString part are lost) and revise — "Matt Todd" <chiology@...> 2008/10/16

You are trying to use GET-style query params instead of POSTing the

[#19378] Constant names in 1.9 — Dave Thomas <dave@...>

When Ruby makes the tIDENTIFIER/tCONSTANT test, it looks to see if the =20=

13 messages 2008/10/18

[#19397] [Feature #666] Enumerable::to_hash — Marc-Andre Lafortune <redmine@...>

Feature #666: Enumerable::to_hash

14 messages 2008/10/20
[#23249] [Feature #666](Rejected) Enumerable::to_hash — Yukihiro Matsumoto <redmine@...> 2009/04/18

Issue #666 has been updated by Yukihiro Matsumoto.

[#19422] Now that lambda has more powerful arguments... — Dave Thomas <dave@...>

is there anything that

24 messages 2008/10/21
[#19423] Re: Now that lambda has more powerful arguments... — Wolfgang N疆asi-Donner <ed.odanow@...> 2008/10/21

Dave Thomas schrieb:

[#19424] Re: Now that lambda has more powerful arguments... — Dave Thomas <dave@...> 2008/10/21

[#19427] Re: Now that lambda has more powerful arguments... — Paul Brannan <pbrannan@...> 2008/10/21

On Wed, Oct 22, 2008 at 04:01:45AM +0900, Dave Thomas wrote:

[#19429] Re: Now that lambda has more powerful arguments... — "David A. Black" <dblack@...> 2008/10/21

Hi --

[#19430] Re: Now that lambda has more powerful arguments... — Paul Brannan <pbrannan@...> 2008/10/21

On Wed, Oct 22, 2008 at 04:38:19AM +0900, David A. Black wrote:

[#19431] Re: Now that lambda has more powerful arguments... — "David A. Black" <dblack@...> 2008/10/21

Hi --

[#19432] Re: Now that lambda has more powerful arguments... — Jim Weirich <jim.weirich@...> 2008/10/21

On Oct 21, 2008, at 4:24 PM, David A. Black wrote:

[#19465] [Bug #680] csv.rb: CSV.parse is too late when encoding is mismatch — Takeyuki Fujioka <redmine@...>

Bug #680: csv.rb: CSV.parse is too late when encoding is mismatch

41 messages 2008/10/24
[#19466] Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is too late when encoding is mismatch) — "Michael Selig" <michael.selig@...> 2008/10/24

Hi,

[#19471] Re: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch) — Martin Duerst <duerst@...> 2008/10/24

A default for the source encoding has been discussed quite a long

[#19473] Re: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch) — "Michael Selig" <michael.selig@...> 2008/10/24

Hi,

[#19474] Re: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch) — Yukihiro Matsumoto <matz@...> 2008/10/24

Hi,

[#19515] String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch)) — "Michael Selig" <michael.selig@...> 2008/10/26

Hi,

[#19517] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch)) — Nobuyoshi Nakada <nobu@...> 2008/10/26

Hi,

[#19518] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch)) — "Michael Selig" <michael.selig@...> 2008/10/26

On Sun, 26 Oct 2008 17:26:32 +1100, Nobuyoshi Nakada <nobu@ruby-lang.org>

[#19522] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch)) — Nobuyoshi Nakada <nobu@...> 2008/10/26

Hi,

[#19525] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch)) — "Michael Selig" <michael.selig@...> 2008/10/26

On Sun, 26 Oct 2008 23:34:26 +1100, Nobuyoshi Nakada <nobu@ruby-lang.org>

[#19531] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch)) — Nobuyoshi Nakada <nobu@...> 2008/10/27

Hi,

[#19532] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch)) — "Michael Selig" <michael.selig@...> 2008/10/27

On Mon, 27 Oct 2008 16:07:54 +1100, Nobuyoshi Nakada <nobu@ruby-lang.org>

[#19533] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch)) — Nobuyoshi Nakada <nobu@...> 2008/10/27

Hi,

[#19535] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch)) — "Michael Selig" <michael.selig@...> 2008/10/27

On Mon, 27 Oct 2008 17:27:57 +1100, Nobuyoshi Nakada <nobu@ruby-lang.org>

[#19538] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch)) — Nobuyoshi Nakada <nobu@...> 2008/10/27

Hi,

[#19540] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch)) — "Michael Selig" <michael.selig@...> 2008/10/27

On Mon, 27 Oct 2008 20:55:32 +1100, Nobuyoshi Nakada <nobu@ruby-lang.org>

[#19546] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch)) — Nobuyoshi Nakada <nobu@...> 2008/10/27

Hi,

[#19480] Re: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch) — James Gray <james@...> 2008/10/24

On Oct 24, 2008, at 1:52 AM, Martin Duerst wrote:

[#19566] GC thought — "Roger Pack" <roger.pack@...>

Here is a recent patch I've been experimenting with--for any advice. [1]

26 messages 2008/10/28
[#19569] Re: GC thought — Ken Bloom <kbloom@...> 2008/10/28

On Tue, 28 Oct 2008 17:02:17 +0900, Roger Pack wrote:

[#19575] Re: GC thought — "Roger Pack" <roger.pack@...> 2008/10/28

> Letting the program continue execution during the mark phase could cause

[#19577] Re: GC thought — Paul Brannan <pbrannan@...> 2008/10/28

On Wed, Oct 29, 2008 at 01:04:52AM +0900, Roger Pack wrote:

[#19596] Re: GC thought — "Robert Klemme" <shortcutter@...> 2008/10/29

2008/10/28 Paul Brannan <pbrannan@atdesk.com>:

[#19590] [Feature #695] More flexibility when combining ASCII-8BIT strings with other encodings — Michael Selig <redmine@...>

Feature #695: More flexibility when combining ASCII-8BIT strings with other encodings

13 messages 2008/10/29
[#19646] Re: [Feature #695] More flexibility when combining ASCII-8BIT strings with other encodings — "Michael Selig" <michael.selig@...> 2008/10/30

Hi,

[ruby-core:19133] Re: Autoload and class definition

From: Tilman Giese <tilman@...>
Date: 2008-10-05 21:39:23 UTC
List: ruby-core #19133
Nobu's point is that your inner "class C" accesses C under the 
assumption that "load_c" will define it. However, this assumption is not 
true as "load_c" will not define C within the scope of F. In my opinion, 
the question is which semantics are more important. Is it more important 
to signal the user that he actually made a mistake by declaring a file 
to load a constant which it in fact did not or is it more important to 
keep the semantics of the class definition to check whether the class is 
already defined and to create a new one if it does not? I personally 
consider the latter more important, i.e. a class definition should never 
raise a NameError.

My two cents,
Tilman

Tomas Matousek wrote:
> "And class definition checks if the class is already defined, to reopen it"
>
> Sure, and that's my point. It checks if it is already defined. If it is not, which is the case since load_c doesn't define C directly in F class, it creates a new class. It doesn't raise NameError.
>
> The example is NOT equivalent with
>
> autoload(:C, "load_c")
> C # => NameError
>
> If you try it you get value 1, not a NameError because lookup algorithm for constant read is different from the one used in class definition:
>
> C:\Temp>type load_c.rb
> module M
>   C = 1
> end
>
> class F
>   include M
> end
>
> C:\Temp>irb
> irb(main):001:0> class F
> irb(main):002:1>   autoload(:C, "load_c")
> irb(main):003:1>   C
> irb(main):004:1> end
> => 1
> irb(main):005:0> exit
>
> C:\Temp>irb
> irb(main):001:0> class F
> irb(main):002:1>   autoload(:C, "load_c")
> irb(main):003:1>   class C
> irb(main):004:2>   end
> irb(main):005:1> end
> NameError: uninitialized constant F::C
>         from (irb):3
> irb(main):006:0>
>
> Tomas
>
> -----Original Message-----
> From: Nobuyoshi Nakada [mailto:nobu@ruby-lang.org]
> Sent: Sunday, October 05, 2008 8:28 AM
> To: ruby-core@ruby-lang.org
> Subject: [ruby-core:19129] Re: Autoload and class definition
>
>   
>> Now, let's do the same using constant auto-loading instead:
>>
>> class F
>>   autoload(:C, "load_c");
>>
>>   class C  # => uninitialized constant F::C (NameError)
>>   end
>> end
>>
>> It seems that autoload repeats the same constant resolution
>> semantics that triggered it (otherwise C would be found in M
>> and TypeError would be raised), yet it raises error if the
>> constant is not found. This seems to be a bug. I would expect
>> no exception.
>>     
>
> That autoload declares C must be defined in load_c, but it
> isn't.  And class definition checks if the class is already
> defined, to reopen it.
>
> Your example is same as:
>
>   autoload(:C, "load_c")
>   C # => NameError
>
> --
> Nobu Nakada
> c
>
>
>
>   


In This Thread

Prev Next