[#25272] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yui NARUSE <redmine@...>

Feature #2032: Change the license to "GPLv2+ or Ruby's original".

51 messages 2009/09/02
[#25368] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Kazuhiko Shiozaki <redmine@...> 2009/09/04

Issue #2032 has been updated by Kazuhiko Shiozaki.

[#25461] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Gregory Brown <gregory.t.brown@...> 2009/09/07

On Fri, Sep 4, 2009 at 1:10 PM, Kazuhiko Shiozaki<[email protected]> wrote:

[#25463] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yukihiro Matsumoto <matz@...> 2009/09/08

Hi,

[#30610] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Shyouhei Urabe <redmine@...> 2010/06/06

Issue #2032 has been updated by Shyouhei Urabe.

[#30611] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yusuke ENDOH <mame@...> 2010/06/06

Hi,

[#30614] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Urabe Shyouhei <shyouhei@...> 2010/06/06

> To avoid enbugging a new bug, we must choose the another solutions.

[#30616] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yusuke ENDOH <mame@...> 2010/06/06

2010/6/6 Urabe Shyouhei <[email protected]>:

[#30652] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Urabe Shyouhei <shyouhei@...> 2010/06/08

(2010/06/06 20:27), Yusuke ENDOH wrote:

[#25285] [Feature #2033] Move Core Development to Git — Run Paint Run Run <redmine@...>

Feature #2033: Move Core Development to Git

75 messages 2009/09/02
[#25299] Re: [Feature #2033] Move Core Development to Git — Eric Hodel <[email protected]> 2009/09/02

On Sep 2, 2009, at 11:19, Run Paint Run Run wrote:

[#25290] [Feature #2033] Move Core Development to Git — Yui NARUSE <redmine@...> 2009/09/02

Issue #2033 has been updated by Yui NARUSE.

[#25297] Re: [Feature #2033] Move Core Development to Git — Jon <jon.forums@...> 2009/09/02

> Some commiter of Ruby live on Windows.

[#25342] Re: [Feature #2033] Move Core Development to Git — Urabe Shyouhei <shyouhei@...> 2009/09/03

Jon wrote:

[#25343] Re: [Feature #2033] Move Core Development to Git — Michal Suchanek <hramrach@...> 2009/09/03

2009/9/4 Urabe Shyouhei <[email protected]>:

[#25345] Re: [Feature #2033] Move Core Development to Git — Urabe Shyouhei <shyouhei@...> 2009/09/03

Michal Suchanek wrote:

[#25306] [Feature #2034] Consider the ICU Library for Improving and Expanding Unicode Support — Run Paint Run Run <redmine@...>

Feature #2034: Consider the ICU Library for Improving and Expanding Unicode Support

16 messages 2009/09/03

[#25394] Unmaintained code (Was: Move Core Development to Git) — Eric Hodel <[email protected]>

On Sep 4, 2009, at 02:16, Urabe Shyouhei wrote:

10 messages 2009/09/05

[#25420] [Bug #2054] Onigurma Isn't Documented — Run Paint Run Run <redmine@...>

Bug #2054: Onigurma Isn't Documented

17 messages 2009/09/05

[#25442] turning off indentation warnings — Aaron Patterson <aaron@...>

Is there a way in 1.9 to turn off only indentation warnings? I like

19 messages 2009/09/06
[#25510] Re: turning off indentation warnings — Nobuyoshi Nakada <nobu@...> 2009/09/10

Hi,

[#25511] [Bug #2079] win32ole's OLEGEN does not create all classes needed when a TLB has more than one class defined — Bruno Antunes <redmine@...>

Bug #2079: win32ole's OLEGEN does not create all classes needed when a TLB has more than one class defined

18 messages 2009/09/10

[#25644] [Bug #2121] mathn/rational destroys Fixnum#/, Fixnum#quo and Bignum#/, Bignum#quo — Charles Nutter <redmine@...>

Bug #2121: mathn/rational destroys Fixnum#/, Fixnum#quo and Bignum#/, Bignum#quo

12 messages 2009/09/19

[#25709] [Bug #2131] f(not x) => syntax error — "James M. Lawrence" <redmine@...>

Bug #2131: f(not x) => syntax error

16 messages 2009/09/22

[#25769] A challenge: Enumerator#next in JRuby — Charles Oliver Nutter <headius@...>

I have a challenge for anyone who wants to discuss, propose

25 messages 2009/09/25
[#25782] Re: A challenge: Enumerator#next in JRuby — Tanaka Akira <akr@...> 2009/09/26

In article <[email protected]>,

[#25820] [Feature #2152] Split functionality of Float#inspect and Float#to_s — Roger Pack <redmine@...>

Feature #2152: Split functionality of Float#inspect and Float#to_s

32 messages 2009/09/28

[#25853] [Bug #2160] JSON can't parse input where top-level object is a string — caleb clausen <redmine@...>

Bug #2160: JSON can't parse input where top-level object is a string

11 messages 2009/09/29

[ruby-core:25256] Re: Module#prepend and Array#prepend

From: Yehuda Katz <wycats@...>
Date: 2009-09-02 03:47:51 UTC
List: ruby-core #25256
On Tue, Sep 1, 2009 at 5:37 PM, David A. Black <[email protected]> wrote:

> Hi --
>
>
> On Tue, 1 Sep 2009, Yehuda Katz wrote:
>
>
>>
>> On Mon, Aug 31, 2009 at 4:09 AM, David A. Black <[email protected]>
>> wrote:
>>      Hi --
>>
>>      On Mon, 31 Aug 2009, Yehuda Katz wrote:
>>
>>
>>
>>            On Sun, Aug 30, 2009 at 10:09 PM, Joel VanderWerf
>>            <[email protected]>
>>            wrote:
>>                 Yehuda Katz wrote:
>>                       class Person
>>                        prepend Exclaimer
>>                       end
>>
>>
>>            Is there some way to make the relationship more
>>            visually obvious?
>>
>>            class Person > Exclaimer
>>            end
>>
>>            class Person
>>             self >> Exclaimer
>>            end
>>
>>
>>            Hmmm... seems potentially a bit visually confusing.
>>            I'm happy with prepend,
>>            in particular if we also make prepend a method on
>>            Array.
>>
>>
>> I like the idea of the reverse #include but I'm not sure about the
>> name. The problem, for me, is that it's *too* array-like. The other
>> related operations don't have that same spatial/collection feel to
>> them. Somehow prepend doesn't sound like it's in the same semantic
>> space as include.
>>
>> Now I'm supposed to pony up a brilliant alternative :-) include! came
>> to mind. The "dangerous" aspect is that it occludes the current
>> version of the method.
>>
>>  module M
>>    def x
>>    end
>>  end
>>
>>  class C
>>    def x
>>    end
>>
>>    include M       # doesn't affect instances
>>    include! M      # blocks this class's same-named methods
>>  end
>>
>> Mind you, I've always been intrigued by the idea of ancestors being
>> a fully read-write array. But the current semantics of include are not
>> very array-like, so I'm not sure about "prepend".
>>
>>
>> We asked Matz about that, and he felt it was a bit *too* much. One major
>> problem is that it would affect classes and not just modules, with more
>> dubious semantics.
>>
>
> True.
>
> One question about the prepend idea:
>
>  module M
>    def x; "M's x"; end
>  end
>
>  module N
>    def x; "N's x"; end
>    prepend M   # or whatever it's called :-)
>  end
>
>  class C
>    include N
>  end
>
> Would N have sacrificed itself, so to speak, to M, so that:
>
>  C.new.x
>
> would print "M's x"?


Yep. But keep in mind that M could call super, which would go to N's x.

-- Yehuda


>
>
>
> David
>
> --
> David A. Black / Ruby Power and Light, LLC / http://www.rubypal.com
> Ruby/Rails training, mentoring, consulting, code-review
> Latest book: The Well-Grounded Rubyist (http://www.manning.com/black2)
>
> September Ruby training in NJ has been POSTPONED. Details to follow.
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

In This Thread

Prev Next