Ezra Zygmuntowicz wrote:
Aparenhtly the term originated as Guerilla patch. As in Guerilla warfare
And it was misunderstood and ended up being called monkey patch. Interesting read here: Monkey patch - Wikipedia
Ah, thank you. Quite informative.
--
James Britt
"Simplicity of the language is not what matters, but
simplicity of use."
- Richard A. O'Keefe in squeak-dev mailing list
Rails does "funny" things. These helpers are usually used from within eruby templates e.g:
<html>
<%= text_field( ... ) %>
</html>
Rails sets up the context in which the templates are executed. He'd have to go into the actual rails source to fix this. OTOH...
Ok just as I thought, Rails is not this dumb <g>
Tom just do
def text_field(*args)
orig_result = super
# modify orig result
end
in app/helpers/application_helper.rb
Or if you want it in a per controller bias app/helpers/<controller>_helper.rb
No monkey-patching required
On Jul 14, 2006, at 1:34 PM, Eric Hodel wrote:
On Jul 14, 2006, at 10:24 AM, Tom Werner wrote:
Eric Hodel wrote:
On Jul 13, 2006, at 5:04 PM, Tom Werner wrote:
Eric Hodel wrote:
You just described subclasses:
Well, the idea is that the 3rd party software is going to be using whatever classes it has always used, so just creating a subclass doesn't get me anywhere because the 3rd party app (i.e. Rails) doesn't give a hoot about my BigNozzleFiretruck.
Can you give a concrete example where this takes place?
My specific purpose is to write a plugin for Rails that adds an option to each form field helper (the ones that create <input> tags) that specifies an appropriate class (since CSS attribute selector support is lacking in IE). So I'm using code like this:
module ActionView
module Helpers
module FormHelper# text
alias_method :__classless_text_field, :text_field
def text_field(object_name, method, options = {})
__classless_text_field(object_name, method, options.merge({:class => (options[:class].to_s + ' text').strip}))
endend
end
endmodule X
def does_something(*options)
p options
end
endmodule Y
def does_something(*options)
super('x', *options)
end
endclass C
include X
include Y
endC.new.does_something 'foo'
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
Indeed, but I think you're being too kind.
On Jul 15, 2006, at 9:37 AM, ara.t.howard@noaa.gov wrote:
On Sat, 15 Jul 2006, Daniel Martin wrote:
Okay, but now if two different files include this exact code, you're
re-generating the same symbols. This is why I used ||=, making your
code:class Symbol
@gensym_count ||= 0
def Symbol.gensym
("__gensym__%X" % @gensym_count += 1).intern
end
endAt the very least, two people using the same exact code to define
gensym shouldn't collide with each other.if two different files have this exact same code inlined the programmer should be shot. if two different files require a third that contains this code then there will be no problem.
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
Hi --
Pe?a wrote:
fr hal:
# Actually it was only last week that I first saw this term
# being used in the Ruby community. I wonder if it's too
# late to squash it?you took a vacation
http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/9699d659bd806203Now people are applying it to Ruby. That bothers me
a little.The term "hacking" used to have a negative slant on it, too. It's not the term,
though, it's the slant that matters. The term can't be taken back, you know?
So what exactly does it mean?Well, because it's derogatory in origin, it's also ambiguous. It's got a nested
image of primates performing informal needlework. Conversely, there's an image
of crafty and agile treeswingers going up into the lofts, the places where the
rigid, upright (sticky and pale) homosapien fails.Plus, I like the irony of Rubyists monkeypatching the word monkeypatching:
gutting it, redefining it, and dangerously executing it in public.
But why dance, in the first place, to the tune of whoever says
whatever about Ruby and/or other scripting languages? No nuance of
"monkeypatching" resonates with anything in or about Ruby -- so why
act under an imperative to enter into a relationship with it?
I know, I know -- my vision of Ruby's design as unified and not split
into programming/metaprogramming, or good/3vi1, or [whatever the
opposite of monkeypatching is]/monkeypatching, is hopelessly Utopian.
I plead guilty.
(Can someone please follow up with a witticism about the Scopes
("monkey") trial? 
David
On Sun, 16 Jul 2006, why the lucky stiff wrote:
On Sat, Jul 15, 2006 at 08:41:17AM +0900, Hal Fulton wrote:
--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
Ruby for Rails => RUBY FOR RAILS (reviewed on
Slashdot, 7/12/2006!)
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
dblack@wobblini.net => me
I say go to the opposite end of the spectrum - let every subtly
different programming technique have a strange and ambiguous name! It
could be just like figure-skating. I mean, why would anyone want to be
just 'jumping' when they could be doing a 'Triple Salchow' followed by
a 'Left-reversed Double Axel'!
/james heads of to code using a Bauhaus loop, followed by a
double-reversed pointer melange. Nice flourish at the end there.
On 7/18/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
How about we call the whole thing "programming", and at the same time
do whatever we can to bring it about that people do this "programming"
thing as intelligently and safely as possible?
--
* J *
~
Logan Capaldo wrote:
Eric Hodel wrote:
Eric Hodel wrote:
You just described subclasses:
Well, the idea is that the 3rd party software is going to be using whatever classes it has always used, so just creating a subclass doesn't get me anywhere because the 3rd party app (i.e. Rails) doesn't give a hoot about my BigNozzleFiretruck.
Can you give a concrete example where this takes place?
My specific purpose is to write a plugin for Rails that adds an option to each form field helper (the ones that create <input> tags) that specifies an appropriate class (since CSS attribute selector support is lacking in IE). So I'm using code like this:
module ActionView
module Helpers
module FormHelper# text
alias_method :__classless_text_field, :text_field
def text_field(object_name, method, options = {})
__classless_text_field(object_name, method, options.merge({:class => (options[:class].to_s + ' text').strip}))
endend
end
endmodule X
def does_something(*options)
p options
end
endmodule Y
def does_something(*options)
super('x', *options)
end
endclass C
include X
include Y
endC.new.does_something 'foo'
--Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliantRails does "funny" things. These helpers are usually used from within eruby templates e.g:
<html>
<%= text_field( ... ) %>
</html>Rails sets up the context in which the templates are executed. He'd have to go into the actual rails source to fix this. OTOH...
Ok just as I thought, Rails is not this dumb <g>
Tom just do
def text_field(*args)
orig_result = super
# modify orig result
endin app/helpers/application_helper.rb
Or if you want it in a per controller bias app/helpers/<controller>_helper.rb
No monkey-patching required
That's quite true, it does work wonderfully in application_helper.rb. Though there's something nice about having the functionality reside in a plugin, making it reusable in a nicer fashion. Thanks for the reminder!
Tom
On Jul 14, 2006, at 1:34 PM, Eric Hodel wrote:
On Jul 14, 2006, at 10:24 AM, Tom Werner wrote:
On Jul 13, 2006, at 5:04 PM, Tom Werner wrote:
--
Tom Werner
Helmets to Hardhats
Software Developer
tom@helmetstohardhats.org
www.helmetstohardhats.org
This is what ActionController::Base::helper is for.
On Jul 14, 2006, at 10:57 AM, Logan Capaldo wrote:
On Jul 14, 2006, at 1:34 PM, Eric Hodel wrote:
On Jul 14, 2006, at 10:24 AM, Tom Werner wrote:
My specific purpose is to write a plugin for Rails that adds an option to each form field helper (the ones that create <input> tags) that specifies an appropriate class (since CSS attribute selector support is lacking in IE). So I'm using code like this:
module ActionView
module Helpers
module FormHelper# text
alias_method :__classless_text_field, :text_field
def text_field(object_name, method, options = {})
__classless_text_field(object_name, method, options.merge({:class => (options[:class].to_s + ' text').strip}))
endend
end
endmodule X
def does_something(*options)
p options
end
endmodule Y
def does_something(*options)
super('x', *options)
end
endclass C
include X
include Y
endC.new.does_something 'foo'
Rails does "funny" things. These helpers are usually used from within eruby templates e.g:
<html>
<%= text_field( ... ) %>
</html>Rails sets up the context in which the templates are executed. He'd have to go into the actual rails source to fix this. OTOH...
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
dblack@wobblini.net wrote:
Hi --
The term "hacking" used to have a negative slant on it, too. It's not the term,
though, it's the slant that matters. The term can't be taken back, you know?
So what exactly does it mean?
Being called a hacker was a badge of honor, an still is among certain groups, but the word has been corrupted for general use.
I read that Wikipedia article on the origins of the term monkey patching; I don't think anyone ever saw it as something to be proud of.
Well, because it's derogatory in origin, it's also ambiguous. It's got a nested
image of primates performing informal needlework. Conversely, there's an image
of crafty and agile treeswingers going up into the lofts, the places where the
rigid, upright (sticky and pale) homosapien fails.
Or not.
Plus, I like the irony of Rubyists monkeypatching the word monkeypatching:
gutting it, redefining it, and dangerously executing it in public.
A public execution of the term would be a Good Thing.
But why dance, in the first place, to the tune of whoever says
whatever about Ruby and/or other scripting languages? No nuance of
"monkeypatching" resonates with anything in or about Ruby -- so why
act under an imperative to enter into a relationship with it?
Agreed. People will use whatever terms they think appropriate in the context of their culture, experience, and expectations. That's not a reason to encourage all behavior or just assume all expression deserve equal footing.
I know, I know -- my vision of Ruby's design as unified and not split
into programming/metaprogramming, or good/3vi1, or [whatever the
opposite of monkeypatching is]/monkeypatching, is hopelessly Utopian.
I plead guilty.(Can someone please follow up with a witticism about the Scopes
("monkey") trial?
Well, monkey patching may be an appropriate term for Python, but given that Ruby is more evolved, we need to call the technique "evolutionary enhancement".
On Sun, 16 Jul 2006, why the lucky stiff wrote:
--
James Britt
"In physics the truth is rarely perfectly clear, and that is certainly
universally the case in human affairs. Hence, what is not surrounded by
uncertainty cannot be the truth."
- R. Feynman
James Adam wrote:
On 7/18/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
How about we call the whole thing "programming", and at the same time
do whatever we can to bring it about that people do this "programming"
thing as intelligently and safely as possible?I say go to the opposite end of the spectrum - let every subtly
different programming technique have a strange and ambiguous name! It
could be just like figure-skating. I mean, why would anyone want to be
just 'jumping' when they could be doing a 'Triple Salchow' followed by
a 'Left-reversed Double Axel'!/james heads of to code using a Bauhaus loop, followed by a
double-reversed pointer melange. Nice flourish at the end there.
Well, I guess we should prepare ourselves to have a lot of threads here entitled "Programming question".
Tom
--
Tom Werner
Helmets to Hardhats
Software Developer
tom@helmetstohardhats.org
www.helmetstohardhats.org
Tom-
If you want to do that methodology in a plugin its as easy as dropping this in the init.rb of a blank plugin:
ActionView::Base.class_eval do
def text_field(*args)
orig_result = super
# modify orig result
end
end
-Ezra
On Jul 14, 2006, at 12:29 PM, Tom Werner wrote:
Logan Capaldo wrote:
On Jul 14, 2006, at 1:34 PM, Eric Hodel wrote:
On Jul 14, 2006, at 10:24 AM, Tom Werner wrote:
Eric Hodel wrote:
On Jul 13, 2006, at 5:04 PM, Tom Werner wrote:
Eric Hodel wrote:
You just described subclasses:
Well, the idea is that the 3rd party software is going to be using whatever classes it has always used, so just creating a subclass doesn't get me anywhere because the 3rd party app (i.e. Rails) doesn't give a hoot about my BigNozzleFiretruck.
Can you give a concrete example where this takes place?
My specific purpose is to write a plugin for Rails that adds an option to each form field helper (the ones that create <input> tags) that specifies an appropriate class (since CSS attribute selector support is lacking in IE). So I'm using code like this:
module ActionView
module Helpers
module FormHelper# text
alias_method :__classless_text_field, :text_field
def text_field(object_name, method, options = {})
__classless_text_field(object_name, method, options.merge({:class => (options[:class].to_s + ' text').strip}))
endend
end
endmodule X
def does_something(*options)
p options
end
endmodule Y
def does_something(*options)
super('x', *options)
end
endclass C
include X
include Y
endC.new.does_something 'foo'
--Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliantRails does "funny" things. These helpers are usually used from within eruby templates e.g:
<html>
<%= text_field( ... ) %>
</html>Rails sets up the context in which the templates are executed. He'd have to go into the actual rails source to fix this. OTOH...
Ok just as I thought, Rails is not this dumb <g>
Tom just do
def text_field(*args)
orig_result = super
# modify orig result
endin app/helpers/application_helper.rb
Or if you want it in a per controller bias app/helpers/<controller>_helper.rb
No monkey-patching required
That's quite true, it does work wonderfully in application_helper.rb. Though there's something nice about having the functionality reside in a plugin, making it reusable in a nicer fashion. Thanks for the reminder!
Tom
My specific purpose is to write a plugin for Rails that adds an option to each form field helper (the ones that create <input> tags) that specifies an appropriate class (since CSS attribute selector support is lacking in IE). So I'm using code like this:
module ActionView
module Helpers
module FormHelper# text
alias_method :__classless_text_field, :text_field
def text_field(object_name, method, options = {})
__classless_text_field(object_name, method, options.merge({:class => (options[:class].to_s + ' text').strip}))
endend
end
endmodule X
def does_something(*options)
p options
end
endmodule Y
def does_something(*options)
super('x', *options)
end
endclass C
include X
include Y
endC.new.does_something 'foo'
Rails does "funny" things. These helpers are usually used from within eruby templates e.g:
<html>
<%= text_field( ... ) %>
</html>Rails sets up the context in which the templates are executed. He'd have to go into the actual rails source to fix this. OTOH...
This is what ActionController::Base::helper is for.
Did you miss the rest of my post where I told him to use helpers? Did the ML slice that part off or something?
On Jul 14, 2006, at 7:09 PM, Eric Hodel wrote:
On Jul 14, 2006, at 10:57 AM, Logan Capaldo wrote:
On Jul 14, 2006, at 1:34 PM, Eric Hodel wrote:
On Jul 14, 2006, at 10:24 AM, Tom Werner wrote:
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
Or, if you want to surround it with an even more positive aura, maybe even
"intelligent design" ?
On Wed, Jul 19, 2006 at 06:07:19AM +0900, James Britt wrote:
dblack@wobblini.net wrote:
>On Sun, 16 Jul 2006, why the lucky stiff wrote:>I know, I know -- my vision of Ruby's design as unified and not split
>into programming/metaprogramming, or good/3vi1, or [whatever the
>opposite of monkeypatching is]/monkeypatching, is hopelessly Utopian.
>I plead guilty.
>
>(Can someone please follow up with a witticism about the Scopes
>("monkey") trial?Well, monkey patching may be an appropriate term for Python, but given
that Ruby is more evolved, we need to call the technique "evolutionary
enhancement".
--
Mauricio Fernandez - http://eigenclass.org - singular Ruby
Hi --
On Wed, 19 Jul 2006, Mauricio Fernandez wrote:
On Wed, Jul 19, 2006 at 06:07:19AM +0900, James Britt wrote:
dblack@wobblini.net wrote:
On Sun, 16 Jul 2006, why the lucky stiff wrote:
I know, I know -- my vision of Ruby's design as unified and not split
into programming/metaprogramming, or good/3vi1, or [whatever the
opposite of monkeypatching is]/monkeypatching, is hopelessly Utopian.
I plead guilty.(Can someone please follow up with a witticism about the Scopes
("monkey") trial?Well, monkey patching may be an appropriate term for Python, but given
that Ruby is more evolved, we need to call the technique "evolutionary
enhancement".Or, if you want to surround it with an even more positive aura, maybe even
"intelligent design" ?
Awww, I was hoping someone would pick up on the "scopes" part
David
--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
Ruby for Rails => RUBY FOR RAILS (reviewed on
Slashdot, 7/12/2006!)
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
dblack@wobblini.net => me
dblack@wobblini.net wrote:
Hi --
I know, I know -- my vision of Ruby's design as unified and not split
into programming/metaprogramming, or good/3vi1, or [whatever the
opposite of monkeypatching is]/monkeypatching, is hopelessly Utopian.
I plead guilty.(Can someone please follow up with a witticism about the Scopes
("monkey") trial?Well, monkey patching may be an appropriate term for Python, but given
that Ruby is more evolved, we need to call the technique "evolutionary
enhancement".Or, if you want to surround it with an even more positive aura, maybe even
"intelligent design" ?Awww, I was hoping someone would pick up on the "scopes" part
I try not to shoot fish in a barrel... not till they evolve
rudimentary legs, anyway.
Hal
On Wed, 19 Jul 2006, Mauricio Fernandez wrote:
On Wed, Jul 19, 2006 at 06:07:19AM +0900, James Britt wrote:
dblack@wobblini.net wrote:
On Sun, 16 Jul 2006, why the lucky stiff wrote:
If it walks like a fish....?
Sean
On 7/19/06, Hal Fulton <hal9000@hypermetrics.com> wrote:
dblack@wobblini.net wrote:
> Hi --
>
> On Wed, 19 Jul 2006, Mauricio Fernandez wrote:
>
>> On Wed, Jul 19, 2006 at 06:07:19AM +0900, James Britt wrote:
>>
>>> dblack@wobblini.net wrote:
>>>
>>>> On Sun, 16 Jul 2006, why the lucky stiff wrote:
>>>
>>>> I know, I know -- my vision of Ruby's design as unified and not split
>>>> into programming/metaprogramming, or good/3vi1, or [whatever the
>>>> opposite of monkeypatching is]/monkeypatching, is hopelessly Utopian.
>>>> I plead guilty.
>>>>
>>>> (Can someone please follow up with a witticism about the Scopes
>>>> ("monkey") trial?
>>>
>>> Well, monkey patching may be an appropriate term for Python, but given
>>> that Ruby is more evolved, we need to call the technique "evolutionary
>>> enhancement".
>>
>> Or, if you want to surround it with an even more positive aura, maybe
>> even
>> "intelligent design" ?
>
> Awww, I was hoping someone would pick up on the "scopes" partI try not to shoot fish in a barrel... not till they evolve
rudimentary legs, anyway.Hal
Sean O'Halpin wrote:
If it walks like a fish....?
cut SeaDuck < Duck
join :flop => :waddle
def flop
"flop.. flop... flop"
end
end
It does now
T.