[#33640] [Ruby 1.9-Bug#4136][Open] Enumerable#reject should not inherit the receiver's instance variables — Hiro Asari <redmine@...>

Bug #4136: Enumerable#reject should not inherit the receiver's instance variables

10 messages 2010/12/08

[#33667] [Ruby 1.9-Bug#4149][Open] Documentation submission: syslog standard library — mathew murphy <redmine@...>

Bug #4149: Documentation submission: syslog standard library

11 messages 2010/12/10

[#33683] [feature:trunk] Enumerable#categorize — Tanaka Akira <akr@...>

Hi.

14 messages 2010/12/12
[#33684] Re: [feature:trunk] Enumerable#categorize — "Martin J. Dst" <duerst@...> 2010/12/12

[#33687] Towards a standardized AST for Ruby code — Magnus Holm <judofyr@...>

Hey folks,

23 messages 2010/12/12
[#33688] Re: Towards a standardized AST for Ruby code — Charles Oliver Nutter <headius@...> 2010/12/12

On Sun, Dec 12, 2010 at 9:55 AM, Magnus Holm <judofyr@gmail.com> wrote:

[#33689] Re: Towards a standardized AST for Ruby code — "Haase, Konstantin" <Konstantin.Haase@...> 2010/12/12

On Dec 12, 2010, at 17:46 , Charles Oliver Nutter wrote:

[#33763] [Ruby 1.9-Bug#4168][Open] WeakRef is unsafe to use in Ruby 1.9 — Brian Durand <redmine@...>

Bug #4168: WeakRef is unsafe to use in Ruby 1.9

43 messages 2010/12/17

[#33815] trunk warnflags build issue with curb 0.7.9? — Jon <jon.forums@...>

As this may turn out to be a 3rd party issue rather than a bug, I'd like some feedback.

11 messages 2010/12/22

[#33833] Ruby 1.9.2 is going to be released — "Yuki Sonoda (Yugui)" <yugui@...>

-----BEGIN PGP SIGNED MESSAGE-----

15 messages 2010/12/23

[#33846] [Ruby 1.9-Feature#4197][Open] Improvement of the benchmark library — Benoit Daloze <redmine@...>

Feature #4197: Improvement of the benchmark library

15 messages 2010/12/23

[#33910] [Ruby 1.9-Feature#4211][Open] Converting the Ruby and C API documentation to YARD syntax — Loren Segal <redmine@...>

Feature #4211: Converting the Ruby and C API documentation to YARD syntax

10 messages 2010/12/26

[#33923] [Ruby 1.9-Bug#4214][Open] Fiddle::WINDOWS == false on Windows — Jon Forums <redmine@...>

Bug #4214: Fiddle::WINDOWS == false on Windows

15 messages 2010/12/27

[ruby-core:33539] Re: [Ruby 1.9-Feature#4085][Open] Refinements and nested methods

From: Shugo Maeda <shugo@...>
Date: 2010-12-03 05:55:35 UTC
List: ruby-core #33539
Hi,

2010/12/2 Yusuke ENDOH <mame@tsg.ne.jp>:
>> My proposal is to use modules as namespaces for refinements. o
>> indentation is a necessary evil. therwise, we need syntax like Java
>> packages and one file for each package.
>
> I'm not against using modules as namespaces and refinement scope,
> but I don't like to see the same module being used for refinement
> and traditional use at the same time.
> Modules for mix-in, modules for collection of helper methods, and
> modules for refinement should be separated, at least, in casual
> use.

I agree with you.  But I don't think Ruby should enforce it.

> We can clearly see that the following module FooExt is only for
> refinement. hus I like this style.
>
> odule FooExt
> efine Foo
> ef ... end
> nd

I don't like this style as the primary way because it can be used for
only one class.
A namespace should be able to have multiple names.

>>> A longer (more "meta-programming-like") name would be appropriate to
>>> the block style, such as Module#refine_class, #refine_class_eval,
>>> #class_eval_with_refinement.
>>
>> Meta-programming means programming on programs, so the non-block style
>> is also a meta-programming feature. hy should only the block style
>> be named more "meta-programming-like"?
>
> I can call it "not for casual use" instead of "meta-programming-
> like."

I see.

>> Could you tell me why
>>
>> efine Foo
>> ef bar; end
>> nd
>>
>> is good but
>>
>> efine Foo do
>> ef bar; end
>> nd
>>
>> is not so good?
>
> Because block includes method definition.  block looks to me
> "dynamic" behavior, while method definition (using `def' keyword)
> looks "static" behavior.
> Of course I know that both are also evaluated dynamically in
> Ruby, but I don't think that Ruby encourages such a style so much.

method definitions don't look static for me, but nari said the same....
My brain might be too optimized for Ruby.

>> I don't know why meta-programming features should have long names.
>> In Ruby, meta-programming is encouraged, and meta-programming features
>> sometimes have a short name such as eval, but rarely have a keyword.
>
> Ah, we found the perception gap between I and you.
> I do NOT think that meta-programming is so encouraged even in Ruby.
> It is like "a trick," and should be used only when it is appropriate.
> If it was really so encouraged, Ruby would not provide many
> syntax, such as `def' and `class.'
>
> And I guess that "eval" just came from Perl.

I guess it's a problem of the term meta-programming, so let's not use
the word.  What I want to say is that I think use frequency of refine
is not so high to require a new keyword, but enough high to have a
nice method name.

To tell the truth, I can accept new keywords refine and using, but I'm
afraid it makes Refinements a Ruby 2.0 feature.

-- 
Shugo Maeda

In This Thread