[#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:33523] Re: [Ruby 1.9-Feature#4085][Open] Refinements and nested methods

From: Yusuke ENDOH <mame@...>
Date: 2010-12-02 14:38:59 UTC
List: ruby-core #33523
Hi,

2010/12/2 Shugo Maeda <shugo@ruby-lang.org>:
> My proposal is to use modules as namespaces for refinements.  So
> indentation is a necessary evil.  Otherwise, 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.

We can clearly see that the following module FooExt is only for
refinement.  Thus I like this style.

  module FooExt
    refine Foo
    def ... end
  end


>> 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.  Why should only the block style
> be named more "meta-programming-like"?

I can call it "not for casual use" instead of "meta-programming-
like."


> Could you tell me why
>
>  refine Foo
>    def bar; end
>  end
>
> is good but
>
>  refine Foo do
>    def bar; end
>  end
>
> is not so good?

Because block includes method definition.  A 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.


> 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.


>> The non-block style has a precedent (Module#include), so, if it is
>> adopted, I agree that any new keyword is not needed.  Otherwise, I
>> prefer a new keyword to a new weird (to me) coding style.
>
> Are precedents so important for innovations?

I like this feature as new OO paradigm, but syntax is another
matter.
I also like traditional syntax design principle --including
"syntax-like convention" such as Kernel#require and #include--
and I want this feature also to respect it.

-- 
Yusuke Endoh <mame@tsg.ne.jp>

In This Thread