83
3
true
2008-05-31T11:22:36+01:00
21796
285
alias_method_chain-limits-extensibility
16048
8994
wontfix
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2009-02-06T20:57:12+00:00
4065
Gaspard Bucher
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
There are two problems with the current implementaton of alias_method_chain.
1) If a method defined in a superclass is aliased, replacing the method in the superclass has no effect:
class A
def foo; "foo" end
end
class B < A
def foo_with_bar; foo_without_bar + " with bar" end
alias_method_chain :foo, :bar
end
class A
def foo; "new foo" end
end
B.new.foo # => "foo with bar"
I would have expected "new foo with bar"
2) While ..._without_... methods can be replaced, replacing ..._with_... methods has no effect:
u = User.find(:first)
u.save # => true
class ActiveRecord::Base
def save_with_validation
raise
end
end
u.save # => true
I would have expected an exception.
I have attached a patch that fixes both problems.
There are two problems with the current implementaton of alias_method_chain.
1) If a method defined in a superclass is aliased, replacing the method in the superclass has no effect:
class A
def foo; "foo" end
end
class B < A
def foo_with_bar; foo_without_bar + " with bar" end
alias_method_chain :foo, :bar
end
class A
def foo; "new foo" end
end
B.new.foo # => "foo with bar"
I would have expected "new foo with bar"
2) While ..._without_... methods can be replaced, replacing ..._with_... methods has no effect:
u = User.find(:first)
u.save # => true
class ActiveRecord::Base
def save_with_validation
raise
end
end
u.save # => true
I would have expected an exception.
I have attached a patch that fixes both problems.
<div><p>
There are two problems with the current implementaton of alias_method_chain.
</p><p>
1) If a method defined in a superclass is aliased, replacing the method in the superclass has no effect:
</p><p>
class A
</p><p>
def foo; "foo" end
</p><p>
end
</p><p>
class B < A
</p><p>
def foo_with_bar; foo_without_bar + " with bar" end
</p><p>
alias_method_chain :foo, :bar
</p><p>
end
</p><p>
class A
</p><p>
def foo; "new foo" end
</p><p>
end
</p><p>
B.new.foo # => "foo with bar"
</p><p>
I would have expected "new foo with bar"
</p><p>
2) While ...<em>without</em>... methods can be replaced, replacing ...<em>with</em>... methods has no effect:
</p><p>
u = User.find(:first)
</p><p>
u.save # => true
</p><p>
class ActiveRecord::Base
</p><p>
def save_with_validation
</p><p>
raise
</p><p>
end
</p><p>
end
</p><p>
u.save # => true
</p><p>
I would have expected an exception.
</p><p>
I have attached a patch that fixes both problems.
</p></div>
0
There are two problems with the current implementaton of alias_method_chain.
1) If a method defined in a superclass is aliased, replacing the method in the superclass has no effect:
class A
def foo; "foo" end
end
class B < A
def foo_with_bar; foo_without_bar + " with bar" end
alias_method_chain :foo, :bar
end
class A
def foo; "new foo" end
end
B.new.foo # => "foo with bar"
I would have expected "new foo with bar"
2) While ..._without_... methods can be replaced, replacing ..._with_... methods has no effect:
u = User.find(:first)
u.save # => true
class ActiveRecord::Base
def save_with_validation
raise
end
end
u.save # => true
I would have expected an exception.
I have attached a patch that fixes both problems.
<div><p>
There are two problems with the current implementaton of alias_method_chain.
</p><p>
1) If a method defined in a superclass is aliased, replacing the method in the superclass has no effect:
</p><p>
class A
</p><p>
def foo; "foo" end
</p><p>
end
</p><p>
class B < A
</p><p>
def foo_with_bar; foo_without_bar + " with bar" end
</p><p>
alias_method_chain :foo, :bar
</p><p>
end
</p><p>
class A
</p><p>
def foo; "new foo" end
</p><p>
end
</p><p>
B.new.foo # => "foo with bar"
</p><p>
I would have expected "new foo with bar"
</p><p>
2) While ...<em>without</em>... methods can be replaced, replacing ...<em>with</em>... methods has no effect:
</p><p>
u = User.find(:first)
</p><p>
u.save # => true
</p><p>
class ActiveRecord::Base
</p><p>
def save_with_validation
</p><p>
raise
</p><p>
end
</p><p>
end
</p><p>
u.save # => true
</p><p>
I would have expected an exception.
</p><p>
I have attached a patch that fixes both problems.
</p></div>
false
2008-05-31T11:22:36+01:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
new
alias_method_chain limits extensibility
2008-05-31T11:22:36+01:00
21796
Tammo Freese
Tammo Freese
http://rails.lighthouseapp.com/projects/8994/tickets/285
1
alias_method_chain is just supposed to be a shortcut for two alias_method statements. Usecase like yours, deserves a solution of it's own.
Thanks.
<div><p>
alias_method_chain is just supposed to be a shortcut for two alias_method statements. Usecase like yours, deserves a solution of it's own.
</p><p>
Thanks.
</p></div>
true
2008-07-11T22:57:17+01:00
21796
---
:tag:
:state: new
285
alias_method_chain-limits-extensibility
0
8994
wontfix
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-07-11T22:57:17+01:00
1366
Pratik
Tammo Freese
http://rails.lighthouseapp.com/projects/8994/tickets/285
1
In your opinion, is it OK that you cannot extend/override any of
rails's ..._with_... methods?
<div><p>
In your opinion, is it OK that you cannot extend/override any of
</p><p>
rails's ...<em>with</em>... methods?
</p></div>
true
2008-07-11T23:40:07+01:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
wontfix
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-07-11T23:40:07+01:00
21796
Tammo Freese
Tammo Freese
http://rails.lighthouseapp.com/projects/8994/tickets/285
1
This seems to be a useful patch that addresses a real problem/limitation, so I'm +1. Plus, it's small and tested; Pratik, maybe you can reconsider?
<div><p>
This seems to be a useful patch that addresses a real problem/limitation, so I'm +1. Plus, it's small and tested; Pratik, maybe you can reconsider?
</p></div>
true
2008-07-29T14:11:33+01:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
wontfix
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-07-29T14:11:33+01:00
19078
Steve Purcell
Tammo Freese
http://rails.lighthouseapp.com/projects/8994/tickets/285
424
1
true
2008-07-29T14:15:32+01:00
21796
---
:assigned_user:
285
alias_method_chain-limits-extensibility
0
8994
wontfix
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-07-29T14:15:32+01:00
1366
Pratik
Tammo Freese
Joshua Peek
http://rails.lighthouseapp.com/projects/8994/tickets/285
424
1
target_method_exists can use instance_method_defined?(false) instead.
<div><p>target_method_exists can use instance_method_defined?(false)
instead.</p></div>
false
2008-09-04T16:13:32+01:00
21796
---
:state: wontfix
285
alias_method_chain-limits-extensibility-2
0
8994
open
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-09-04T16:13:32+01:00
83
DHH
Tammo Freese
Joshua Peek
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
1
-1 I don't like the idea of replacing the alias with a delegate method call.
@David I think that only cleans up the "target_method_exists = (instance_methods + private_instance_methods).include?(RUBY_VERSION < '1.9' ? with_method : with_method.to_sym)" busy.
<div><p>-1 I don't like the idea of replacing the alias with a delegate
method call.</p>
<p>@David I think that only cleans up the "target_method_exists =
(instance_methods + private_instance_methods).include?(RUBY_VERSION
< '1.9' ? with_method : with_method.to_sym)" busy.</p></div>
false
2008-09-07T16:12:51+01:00
21796
---
:assigned_user: 424
285
alias_method_chain-limits-extensibility
0
8994
open
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-09-07T16:13:08+01:00
424
Joshua Peek
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
1
The reason for this is to allow someone to overwrite part of the chain to inject their own behavior. Which I think is very reasonable. If you have another way of achieving the same result, let's discuss that.
Tammo, perhaps you can post the full example somewhere so Josh can see the use case? I didn't really care for this much until I saw the use case either.
<div><p>The reason for this is to allow someone to overwrite part of the
chain to inject their own behavior. Which I think is very
reasonable. If you have another way of achieving the same result,
let's discuss that.</p>
<p>Tammo, perhaps you can post the full example somewhere so Josh
can see the use case? I didn't really care for this much until I
saw the use case either.</p></div>
false
2008-09-07T19:22:45+01:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
open
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-09-07T19:22:59+01:00
83
DHH
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
1
Using alias_method instead of a delegate method call makes overwriting/
extending _with_ methods a major pain.
Let's say you would like to disable benchmarking, but keep the logger
for the rest of the application
(or you would like to implement your own benchmarking).
The code
class ActionController::Base
def perform_action_with_benchmark(*args, &block)
perform_action_without_benchmark(*args, &block)
end
end
looks right, but does not work, since overwriting _with_ methods has
no effect at all.
It is possible to workaround that, but the resulting code
a) looks like an implementation error, and
b) depends on the exact order of the chaining in rails:
class ActionController::Base
def perform_action_without_rescue(*args, &block)
perform_action_without_benchmark(*args, &block)
end
end
<div><p>Using alias_method instead of a delegate method call makes
overwriting/ extending <em>with</em> methods a major pain.</p>
<p>Let's say you would like to disable benchmarking, but keep the
logger for the rest of the application (or you would like to
implement your own benchmarking).</p>
<p>The code</p>
<p>class ActionController::Base def
perform_action_with_benchmark(*args, &block)</p>
<pre>
<code> perform_action_without_benchmark(*args, &block)
</code>
</pre>
<p>end end</p>
<p>looks right, but does not work, since overwriting <em>with</em>
methods has no effect at all.</p>
<p>It is possible to workaround that, but the resulting code</p>
<p>a) looks like an implementation error, and b) depends on the
exact order of the chaining in rails:</p>
<p>class ActionController::Base def
perform_action_without_rescue(*args, &block)</p>
<pre>
<code> perform_action_without_benchmark(*args, &block)
</code>
</pre>
<p>end end</p></div>
false
2008-09-07T21:50:08+01:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
open
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-09-07T21:50:18+01:00
21796
Tammo Freese
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
1
The use case seems reasonable. I wonder if aliasing it back works?
@@@ ruby
alias_method :perform_action, :perform_action_without_benchmark
@@@
I also think those (ActionController) mixins should be done without alias_method_chain. Another ticket for another day.
<div><p>The use case seems reasonable. I wonder if aliasing it back
works?</p>
<pre><code class="ruby">
alias_method :perform_action, :perform_action_without_benchmark
</code></pre>
<p>I also think those (ActionController) mixins should be done
without alias_method_chain. Another ticket for another day.</p></div>
false
2008-09-07T23:14:07+01:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
open
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-09-07T23:14:14+01:00
424
Joshua Peek
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
1
Hello Joshua,
aliasing back will not work correctly.
alias_method :perform_action, :perform_action_without_benchmark
will disable benchmarking,
but it will disable a lot more than that, since it throws out
every aspect added to perform_action after benchmarking.
In Rails 2.1, this would mean that
- rescue_from would not work anymore,
- action caching would not work anymore,
- every plugin extension to perform_action would be lost.
<div><p>Hello Joshua,</p>
<p>aliasing back will not work correctly.</p>
<p>alias_method :perform_action,
:perform_action_without_benchmark</p>
<p>will disable benchmarking, but it will disable a lot more than
that, since it throws out every aspect added to perform_action
after benchmarking.</p>
<p>In Rails 2.1, this would mean that - rescue_from would not work
anymore, - action caching would not work anymore, - every plugin
extension to perform_action would be lost.</p></div>
false
2008-09-08T08:06:27+01:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
open
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-09-08T08:16:20+01:00
21796
Tammo Freese
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
1
Is swapping out ActionController benchmark your real goal, or was it just an example? If it is, I'd like to see how we can do this w/o alias_method_chain.
<div><p>Is swapping out ActionController benchmark your real goal, or
was it just an example? If it is, I'd like to see how we can do
this w/o alias_method_chain.</p></div>
false
2008-09-08T15:49:26+01:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
open
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-09-08T15:49:31+01:00
424
Joshua Peek
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
1
We found the problem with …_with_… methods when implementing a custom
benchmarking.
However, in my opinion, every …_with_… method in rails is a potential
extension point for
an application or a plugin, and should therefore be extensible.
<div><p>We found the problem with …<em>with</em>… methods
when implementing a custom benchmarking.</p>
<p>However, in my opinion, every …<em>with</em>… method
in rails is a potential extension point for an application or a
plugin, and should therefore be extensible.</p></div>
false
2008-09-09T11:15:08+01:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
open
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-09-09T11:15:17+01:00
21796
Tammo Freese
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
1
Hi,
I started a few blog posts on http://ruby.simapse.com about the decorator pattern and alias_method_chain. You might want to have a look.
Anyhow a suggested approach would be to move (almost?) all instance methods of ActiveRecord::Base into the module ActiveRecord::Core, and put the later on top of all decorating modules (Core makes sens since it's the one to be deCOREated).
Their would be no aliasing, the method_without_feature is replaced by super and voila, that's it.
I gave it a try on 'save' and all the tests (cases/base) passed.
With/without methods are gone there's just one and only save (seems to me less messy when you have many decorators).
If i want to save without transaction, i override save in :
module AR::Transaction
def save; super; end
end
Simple, easy, consistant and i don't think you loose any convinience alias_method_chain brings you, and it should break anything (or not much). I still have to dig in though.
Attached is my patch with save.
If you think it's worth the try i can go on and refactor it for every method exposed in AR::Base on a github fork.
cheers
<div><p>Hi,</p>
<p>I started a few blog posts on <a href="http://ruby.simapse.com">http://ruby.simapse.com</a> about the
decorator pattern and alias_method_chain. You might want to have a
look.</p>
<p>Anyhow a suggested approach would be to move (almost?) all
instance methods of ActiveRecord::Base into the module
ActiveRecord::Core, and put the later on top of all decorating
modules (Core makes sens since it's the one to be deCOREated).</p>
<p>Their would be no aliasing, the method_without_feature is
replaced by super and voila, that's it.</p>
<p>I gave it a try on 'save' and all the tests (cases/base)
passed.</p>
<p>With/without methods are gone there's just one and only save
(seems to me less messy when you have many decorators). If i want
to save without transaction, i override save in :</p>
<p>module AR::Transaction def save; super; end end</p>
<p>Simple, easy, consistant and i don't think you loose any
convinience alias_method_chain brings you, and it should break
anything (or not much). I still have to dig in though.</p>
<p>Attached is my patch with save.</p>
<p>If you think it's worth the try i can go on and refactor it for
every method exposed in AR::Base on a github fork.</p>
<p>cheers</p></div>
false
2008-09-21T23:01:04+01:00
21796
---
:tag: activesupport alias_method_chain patch
285
alias_method_chain-limits-extensibility
0
8994
open
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-09-21T23:01:09+01:00
32634
charly71
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
2
Hello charly71,
I see three problems with this approach:
1) To decorate one of the save methods in the modules (extending it, not overriding it) you would still need to resort to alias_method_chain or something similar.
2) You lose the possiblity to call the with/without methods directly on the objects. (I can't tell for sure whether this is needed or not.)
3) You can only extend inside the module itself, but not inside classes or subclasses. As a result, you cannot restrict an extension to a subtree of the inheritance hierarchy, but it's always all or nothing. As an example, you cannot easily disable benchmarking for a single subclass of ActionController::Base, but
only globally.
<div><p>Hello charly71,</p>
<p>I see three problems with this approach:</p>
<p>1) To decorate one of the save methods in the modules (extending
it, not overriding it) you would still need to resort to
alias_method_chain or something similar.</p>
<p>2) You lose the possiblity to call the with/without methods
directly on the objects. (I can't tell for sure whether this is
needed or not.)</p>
<p>3) You can only extend inside the module itself, but not inside
classes or subclasses. As a result, you cannot restrict an
extension to a subtree of the inheritance hierarchy, but it's
always all or nothing. As an example, you cannot easily disable
benchmarking for a single subclass of ActionController::Base, but
only globally.</p></div>
false
2008-09-25T16:12:00+01:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
open
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-09-25T16:12:03+01:00
21796
Tammo Freese
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
2
Hi Tammo,
yes i got immediatly aware of no 3) after posting and felt stupid.
regarding no 2) the problem is when you call save_without_transaction, you're probably calling save_with_validation and save_with_dirty, and it is a bit misleading (you're not calling the pure, immaculate save...). Even though it is probably what you want, it doesn't give you more modularity (cherrypicking) than having a chain of 'super' called.
I do agree though that if you want to override (for just one model down the inheritance chain) your benchmarking or transaction or whatever you'll have to resolve to some magic (which still needs to be boiled in the pot) BUT..... only in your plugin :
module MyValidation
skip :save, :in=>Validation
def save
"blah"; super; "blah"
end
end
Yet i'm speculating because i haven't resolved the magic piece ('super' is giving me some headaches, hum any ruby ninja around ?)
<div><p>Hi Tammo,</p>
<p>yes i got immediatly aware of no 3) after posting and felt
stupid.</p>
<p>regarding no 2) the problem is when you call
save_without_transaction, you're probably calling
save_with_validation and save_with_dirty, and it is a bit
misleading (you're not calling the pure, immaculate save...). Even
though it is probably what you want, it doesn't give you more
modularity (cherrypicking) than having a chain of 'super'
called.</p>
<p>I do agree though that if you want to override (for just one
model down the inheritance chain) your benchmarking or transaction
or whatever you'll have to resolve to some magic (which still needs
to be boiled in the pot) BUT..... only in your plugin :</p>
<p>module MyValidation skip :save, :in=>Validation def save
"blah"; super; "blah" end end</p>
<p>Yet i'm speculating because i haven't resolved the magic piece
('super' is giving me some headaches, hum any ruby ninja around
?)</p></div>
false
2008-09-25T17:40:24+01:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
open
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-09-25T17:40:27+01:00
32634
charly71
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
2
Hi again,
i hope i'm not polluting this ticket, but since Joshua said mixins in ActionController should be done without alias_method_chain...
Anyway the attached code says it all and adresses a lot of issues.
The uninclude file was taken from here :
http://github.com/yrashk/rbmodexcl/tree/master.
It is then easy to skip a module on the fly unincluding and reincluding. I'm not sure whats the drawbacks or limitations but it certainly opens up the possibilities.
<div><p>Hi again,</p>
<p>i hope i'm not polluting this ticket, but since Joshua said
mixins in ActionController should be done without
alias_method_chain...</p>
<p>Anyway the attached code says it all and adresses a lot of
issues.</p>
<p>The uninclude file was taken from here :</p>
<p><a href="http://github.com/yrashk/rbmodexcl/tree/master.%3C/p">http://github.com/yrashk/rbmodex...</a>></p>
<p>It is then easy to skip a module on the fly unincluding and
reincluding. I'm not sure whats the drawbacks or limitations but it
certainly opens up the possibilities.</p></div>
false
2008-09-26T15:43:21+01:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
open
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-09-26T15:43:26+01:00
32634
charly71
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
3
alias_method_chain makes easy AOP, while we need it more manageable, like "insert new feature to specified position of the chain", "rewrite/remove/move specified feature of the chain", "call pure function", etc.
thus, chain should be exposed and can be operated, and features in it should be manageable. all of them are not only behaviours to be execute, but also data structures can be operated.
big project?
I think it makes sense. just a suggestion to core team to consider.
I even like it be in ruby grammar(I prefer ruby includes raw event-driven support, annotation support...) -- brainstorm :)
<div><p>alias_method_chain makes easy AOP, while we need it more
manageable, like "insert new feature to specified position of the
chain", "rewrite/remove/move specified feature of the chain", "call
pure function", etc. thus, chain should be exposed and can be
operated, and features in it should be manageable. all of them are
not only behaviours to be execute, but also data structures can be
operated.</p>
<p>big project?</p>
<p>I think it makes sense. just a suggestion to core team to
consider.</p>
<p>I even like it be in ruby grammar(I prefer ruby includes raw
event-driven support, annotation support...) -- brainstorm :)</p></div>
false
2008-10-07T03:47:47+01:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
open
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-10-07T03:47:48+01:00
31686
sliu
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
3
finally, I find class Hook in merb's extlib fit my needs.
much appreciate to rails team who bring and maintain the amazing rails framework.
I have a big dream: keep open mind to merge rails and merb community together.
rails and merb are now more like struts and webwork, they finally merged their projects and communities.
I think whether the dream can be realized primarily depends on not tech, not history. IT IS ALL ABOUT PEOPLE WHO OWE THEM.
<div><p>finally, I find class Hook in merb's extlib fit my needs.</p>
<p>much appreciate to rails team who bring and maintain the amazing
rails framework.</p>
<p>I have a big dream: keep open mind to merge rails and merb
community together.</p>
<p>rails and merb are now more like struts and webwork, they
finally merged their projects and communities.</p>
<p>I think whether the dream can be realized primarily depends on
not tech, not history. IT IS ALL ABOUT PEOPLE WHO OWE THEM.</p></div>
false
2008-11-17T07:09:54+00:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
open
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2008-11-17T07:09:58+00:00
31686
sliu
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
3
Yehuda is out to kill alias_method_chain. Expect it to be gone in 3.0 ;)
<div><p>Yehuda is out to kill alias_method_chain. Expect it to be gone
in 3.0 ;)</p></div>
true
2009-01-19T19:14:20+00:00
21796
---
:state: open
285
alias_method_chain-limits-extensibility
0
8994
wontfix
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2009-01-19T19:14:23+00:00
424
Joshua Peek
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
83
3
Good to know Yehuda is on this. This method chaining has always been hard to adapt or debug.
I am very curious to know what he comes up with !
<div><p>Good to know Yehuda is on this. This method chaining has always
been hard to adapt or debug.</p>
<p>I am very curious to know what he comes up with !</p></div>
true
2009-02-06T20:57:11+00:00
21796
--- {}
285
alias_method_chain-limits-extensibility
0
8994
wontfix
activesupport alias_method_chain patch
alias_method_chain limits extensibility
2009-02-06T20:57:12+00:00
4065
Gaspard Bucher
Tammo Freese
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/285
47d73219f3ebcd99b82dad8a0a45dce5d21317b4
text/plain
2008-05-31T11:22:36+01:00
fixes-for-alias-method-chain.diff
25262
4759
21796
http://rails.lighthouseapp.com/attachments/25262/fixes-for-alias-method-chain.diff
2d90a594ee55fbe5645100d6d9a2f35e6f8a23e5
text/plain
2008-09-21T23:01:05+01:00
rails_without_alias_method_chain_.txt
47507
5668
32634
http://rails.lighthouseapp.com/attachments/47507/rails_without_alias_method_chain_.txt
3f3b40a15e0f554932f3ee74d7a2a883ecf41ec0
application/octet-stream
2008-09-26T15:43:21+01:00
model-decorator-overide.rb
48899
918
32634
http://rails.lighthouseapp.com/attachments/48899/model-decorator-overide.rb