[#61822] Plan Developers Meeting Japan April 2014 — Zachary Scott <e@...>
I would like to request developers meeting around April 17 or 18 in this month.
14 messages
2014/04/03
[#61825] Re: Plan Developers Meeting Japan April 2014
— Urabe Shyouhei <shyouhei@...>
2014/04/03
It's good if we have a meeting then.
[#61826] Re: Plan Developers Meeting Japan April 2014
— Zachary Scott <e@...>
2014/04/03
Regarding openssl issues, I’ve discussed possible meeting time with Martin last month and he seemed positive.
[#61833] Re: Plan Developers Meeting Japan April 2014
— Martin Bo煬et <martin.bosslet@...>
2014/04/03
Hi,
[#61847] Re: Plan Developers Meeting Japan April 2014
— Eric Wong <normalperson@...>
2014/04/03
Martin Boテ殕et <martin.bosslet@gmail.com> wrote:
[#61849] Re: Plan Developers Meeting Japan April 2014
— Zachary Scott <e@...>
2014/04/04
I will post summary of meeting on Google docs after the meeting.
[#61852] Re: Plan Developers Meeting Japan April 2014
— Eric Wong <normalperson@...>
2014/04/04
Zachary Scott <e@zzak.io> wrote:
[#61860] Re: Plan Developers Meeting Japan April 2014
— Zachary Scott <e@...>
2014/04/04
I’m ok with redmine, thanks for bringing up your concern!
[#62076] Candidacy to 2.1 branch maintainer. — Tomoyuki Chikanaga <nagachika00@...>
Hello,
7 messages
2014/04/17
[#62078] Re: Candidacy to 2.1 branch maintainer.
— SHIBATA Hiroshi <shibata.hiroshi@...>
2014/04/17
> And does anyone have counter proposal for 2.1 maintenance?
[ruby-core:61830] Re: [ruby-trunk - Feature #9696] [Open] More Flexible Refinement Syntax
From:
Rodrigo Rosenfeld Rosas <rr.rosas@...>
Date:
2014-04-03 09:54:32 UTC
List:
ruby-core #61830
For a practical solution you might be interested on you might build a preprocessor that would generate the duplicate files you need which could be ignored by your VCS but included in your gem. Em 03/04/2014 00:22, <transfire@gmail.com> escreveu: > Issue #9696 has been reported by Thomas Sawyer. > > ---------------------------------------- > Feature #9696: More Flexible Refinement Syntax > https://bugs.ruby-lang.org/issues/9696 > > * Author: Thomas Sawyer > * Status: Open > * Priority: Normal > * Assignee: > * Category: core > * Target version: current: 2.2.0 > ---------------------------------------- > I am the maintainer of Ruby Facets, the core extensions library. For the > next release of Facets I have long planned to provide support for > Refinements. Unfortunately, after working with the code to determine what > would be necessary to support them, I've come to the conclusion that it's > just not reasonable to do so. The problem lies in the fact that Facets must > still be backward compatible with it's "monkey-patch" usage. In fact, that > usage is sometimes preferable b/c you can require once and don't have to > write `using Foo` in every file that a core extension might be needed. But, > b/c of the syntax that refinements use, to support both patching and > refining I would have to maintain TWO COPIES of every extension, which > simply isn't practical. > > For example, the normal definition of a String#foo: > > ~~~ > class String > def foo > ... > end > end > ~~~ > > And the refinement: > > ~~~ > module Facets > refine String do > def foo > ... > end > end > end > ~~~ > > There does not appear to be any reasonable way to have the definition > defined once and still be able to be use it in either manner. (Also, I want > to point out that refinements do not lend themselves to cherry picking > specific methods per-file either.) > > So, unless someone has a clever approach that I have not thought of, I > wonder if it would not be a good idea to reconsider the syntax of > refinements. Would it be possible to simplify the definition to use `class` > instead of `refine`, e.g. > > ~~~ > module Facets > class String > def foo > ... > end > end > end > ~~~ > > And then allow `using Facets` which would refine any common class is the > scope. And further, allowing also `using Facets::String` and even `using > Facets::String::foo` to cherry pick refinements? In addition, a way to > "apply" a module as if it were evaluated in the scope. This would then > allow the same code to be used either as a refinement or as an extension. > > Alternatively, maybe refinements should just be a require --if they will > forever remain at the file-level. Then no special syntax would be needed at > all. Simply defining them in a separate file, e.g. > > ~~~ > # string/foo.rb > class String > def foo > ... > end > end > ~~~ > > And then "using" them by file name instead would do the trick. > > ~~~ > using 'string/foo' > ~~~ > > > > > > -- > https://bugs.ruby-lang.org/ >