[#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:61882] [ruby-trunk - Feature #9704] Refinements as files instead of modules
From:
transfire@...
Date:
2014-04-06 16:52:26 UTC
List:
ruby-core #61882
Issue #9704 has been updated by Thomas Sawyer.
Yes, the transition from monkey-patching to refinements is a major part of the intention.
But I also do not expect monkey-patching to ever completely go away. (Do you?) Monkey patching is more convenient, in that it can be done via one require for an entire project, where as refining has to specified per-file. So there will be cases where monkey-patching is still preferred.
Besides personal projects and small end-user tools, a good example, I think, is ActiveSupport. While some of it could be used as refinements, I suspect much of it will remain core extensions b/c it represents Rails' DSL, so to speak. And the parts that can become refinements, I would imagine users would still have an option to load them in as extensions.
Even so, I think the main intent is to ask the question: Do refinements *need* to be modules? If there is no compelling reason for them to be so, then making refinements file-based would simplify reuse and allow us to shed unnecessary boiler-plate.
----------------------------------------
Feature #9704: Refinements as files instead of modules
https://bugs.ruby-lang.org/issues/9704#change-46094
* Author: Thomas Sawyer
* Status: Open
* Priority: Normal
* Assignee:
* Category: core
* Target version: Next Major
----------------------------------------
If refinements are to remain file-scoped, then it would be more convenient if `using` worked at the file level, akin to `require`, rather than behave like a module `include`. For instance, instead of:
~~~
# foo.rb
module Foo
refine String do
def some_method
...
end
end
end
~~~
~~~
require 'foo'
using Foo
~~~
We could do:
~~~
# foo.rb
class String
def some_method
...
end
end
~~~
~~~
using 'foo'
~~~
This would make `require` and `using`, in a certain sense, *polymorphic* --if we `require` it will extend the classes directly, but if `using` then they will be refined instead.
--
https://bugs.ruby-lang.org/