>I haven't noticed invoke_functional_method. I admit I'm still unclear
>on the (new?) use of the notion of 'function' in addition to
>'method'.... How do you characterize a functional method, in this
>context?
I refer a method invocation without a receiver specified as
"functional style" because it looks like function calls in other
languages. The name "funcall" and "invoke_functional_method" reflect
that term.
I'm not clear on what you mean. Don't these all have receivers?
I would still say that "send" is a better fit for explicitly sending a
message to an object. With 'call' and 'invoke' you're saying to the
object: here's a message *and* here's what you should do with it. I
think the caller should send the message -- even a meta-message, as
with send -- and the object should decide what's going to happen.
David
···
On Tue, 4 Jul 2006, Yukihiro Matsumoto wrote:
In message "Re: About 1.9 #__method__ feature." > on Tue, 4 Jul 2006 00:59:21 +0900, dblack@wobblini.net writes:
--
"To fully realize the potential of Rails, it's crucial that you take
the time to fully understand Ruby--and with "Ruby for Rails" David
has provided just what you need to help you achieve that goal."
-- DAVID HEINEMEIER HANSSON, in the foreword to RUBY FOR RAILS.
Complete foreword & sample chapters at http://www.manning.com/black\!
that seems to be pretty silly logic to me because there is always a method
name that will collide with someone's design. rather than cater to those 5%
of cases why not simply allow them to alias send to whatever they want? it's
pretty easy to do
class Object
alias_method '__super_secret_send__', 'send'
end
alternatively we could stash all the methods that need to be hidden under a
special object or name, something like
obj.internal :send, 'msg', 'arg'
or
obj.internal{ send 'msg, 'arg' }
or, given that it's actually a valid identifier
_(obj){ send 'msg', 'arg' }
obviously these are just ideas, and probably bad ones, but it just seems to be
a waist of time to come up with 42 methods that won't collide with people's
own code. why not just come up with one single way of entering an object's
stash of 'super special and shouldn't/can't be overridden methods' and use it
for them all? then the issue is solved generically and consistently.
2cts.
-a
···
On Sun, 9 Jul 2006 transfire@gmail.com wrote:
dblack@wobblini.net wrote:
Maybe Sean was right that you and I are really saying the same thing
in different ways At least, we seem to have converged on "send!".
But Matz want's to get away from #send, and for good reason -- it's too
likely to be overriden, which is the whole reason we ended up with
__send__. So by it's very nature it needs to be more unique and there
are only two ways to achieve that: make it longer or make it esoteric.
I prefer longer.
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama
On Tue, Jul 04, 2006 at 01:00:30AM +0900, dblack@wobblini.net wrote:
hmmm the link between "might be called externally despite being private"
and "functional" is subtle, to say the least; #invoke_private_method seems
much clearer (even if inaccurate) and is nearly as long if you want to
discourage its use.
I think it's inaccurate to the point of really not being usable.
Conceded. #invoke_even_if_private also came to mind but it seems a bit
excessive.
I admit I'm still a fan of send/send! but I guess they're long gone
I also like it (! never really meant "danger" to me).
I like it too, and ! always *did* mean "danger" to me (And to
Matz, I always thought, but maybe I'm out of date.) The "danger" in
this case is the inclusion of methods you normally wouldn't be able to
call and might not even know about.
David
--
"To fully realize the potential of Rails, it's crucial that you take
the time to fully understand Ruby--and with "Ruby for Rails" David
has provided just what you need to help you achieve that goal."
-- DAVID HEINEMEIER HANSSON, in the foreword to RUBY FOR RAILS.
Complete foreword & sample chapters at http://www.manning.com/black\!
>Using BasicObject as parent removes (almost) all kernel methods which
>ensures no name clashes when using the OpenObject. Problem is sometimes
>those removed methods are needed. So the important ones are available
>by shadow methods, like __send__ even though #send is removed. Problem
>is A) how many and which kernel methods should be shadowed; all of
>them? and worse B) it means users have to be aware when a subclass of
>BasicObject might be used and call the LCD, ie. shadow methods instead
>of regular methods.
I don't know what you expect for BasicObject and OpenObject.
BasicObject is a BasicObject what it is. Could you describe what you
want and what you expect first please? BasicObject may not be the
answer for your problem. If it's not the right answer, tweaking it to
adopt your requirement might not be a good idea.
OpenObject is just like OpenStruct, but it is faster and removes
methods that would get in thte way using BasicObject, for example #class.
Hmm, and you cannot use private methods in the subclass of OpenObject.
What should we do? Maybe you can define your own version of
BlankSlate that makes every required method into private, instead of
undef'ing it.
I just revisited separating two namespaces, but it would break 80-90%
of Ruby programs. Even though I accept _some_ code breakage in 1.9,
it's just too much.
matz.
···
In message "Re: About 1.9 #__method__ feature." on Tue, 4 Jul 2006 03:11:04 +0900, transfire@gmail.com writes:
What about "invoke_function"? It's not accurate but mixing, "function" and
"method" in the same name seems to be mixing two concepts that are mutually
exclusive. Like saying "blackish white".
Hmm. Let me consider.
BTW I also like the send/send! syntax (not that it seems to matter at this point)
And invoke_method and invoke_method! as well?
matz.
···
In message "Re: About 1.9 #__method__ feature." on Tue, 4 Jul 2006 11:46:03 +0900, Daniel DeLorme <dan-ml@dan42.com> writes:
I've somtimes wanted a way to get at the binding of the caller but Binding.of_caller is just too much of a hack and I can't bring myself to use it. But this would be a very elegant solution.
I'd prefer having the functionality built-in as well. It might happen in the next few years from what I understand.
In message "Re: About 1.9 #__method__ feature." on Tue, 4 Jul 2006 21:26:00 +0900, dblack@wobblini.net writes:
I refer a method invocation without a receiver specified as
"functional style" because it looks like function calls in other
languages. The name "funcall" and "invoke_functional_method" reflect
that term.
I'm not clear on what you mean. Don't these all have receivers?
They have receivers. But they are not "specified" for functional
styles.
>> >Using BasicObject as parent removes (almost) all kernel methods which
>> >ensures no name clashes when using the OpenObject. Problem is sometimes
>> >those removed methods are needed. So the important ones are available
>> >by shadow methods, like __send__ even though #send is removed. Problem
>> >is A) how many and which kernel methods should be shadowed; all of
>> >them? and worse B) it means users have to be aware when a subclass of
>> >BasicObject might be used and call the LCD, ie. shadow methods instead
>> >of regular methods.
>>
>> I don't know what you expect for BasicObject and OpenObject.
>> BasicObject is a BasicObject what it is. Could you describe what you
>> want and what you expect first please? BasicObject may not be the
>> answer for your problem. If it's not the right answer, tweaking it to
>> adopt your requirement might not be a good idea.
>
>OpenObject is just like OpenStruct, but it is faster and removes
>methods that would get in thte way using BasicObject, for example
>#class.
Hmm, and you cannot use private methods in the subclass of OpenObject.
What should we do? Maybe you can define your own version of
BlankSlate that makes every required method into private, instead of
undef'ing it.
Yes!!! I had totally forgotten about that little trick with
method_missing catching public calls to otherwise private methods. Can
I always depend on Ruby working that way? If so I think it's all good.
I just revisited separating two namespaces, but it would break 80-90%
of Ruby programs. Even though I accept _some_ code breakage in 1.9,
it's just too much.
Yes, too much. And too much complexity --you are right. Like a child
learning, my initial solutions tend to overreach. It's not that we need
to totally separate public and private methods, rather we need only be
able to act according to which is invoked. The method_missing trick
should work perfectly.
Thank you Matz! I'm working on this tonight!
T.
···
In message "Re: About 1.9 #__method__ feature." > on Tue, 4 Jul 2006 03:11:04 +0900, transfire@gmail.com writes:
>BTW I also like the send/send! syntax (not that it seems to matter at this point)
And invoke_method and invoke_method! as well?
FWIW, I also like "send!" *much* more than "funcall". The only thing bothering me: for classes with their own "send" method, "send" and "send!" wouldn't be related to each other.
Therefore I prefer "invoke_method" and "invoke_method!". I would even deprecate "send" if it wouldn't break so much code.
I've somtimes wanted a way to get at the binding of the caller but
Binding.of_caller is just too much of a hack and I can't bring myself to
use it. But this would be a very elegant solution.
I'd prefer having the functionality built-in as well. It might happen in the next few years from what I understand.
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama
In message "Re: About 1.9 #__method__ feature." > on Tue, 4 Jul 2006 21:26:00 +0900, dblack@wobblini.net writes:
>> I refer a method invocation without a receiver specified as
>> "functional style" because it looks like function calls in other
>> languages. The name "funcall" and "invoke_functional_method" reflect
>> that term.
>
>I'm not clear on what you mean. Don't these all have receivers?
They have receivers. But they are not "specified" for functional
styles.
Can you show me an example? I'm still not understanding. I'm
thinking of:
obj.funcall(:meth)
but maybe there's a different/new syntax for funcall? Is it now a
top-level method?
David
--
"To fully realize the potential of Rails, it's crucial that you take
the time to fully understand Ruby--and with "Ruby for Rails" David
has provided just what you need to help you achieve that goal."
-- DAVID HEINEMEIER HANSSON, in the foreword to RUBY FOR RAILS.
Complete foreword & sample chapters at http://www.manning.com/black\!
In message "Re: About 1.9 #__method__ feature." on Tue, 4 Jul 2006 10:35:23 +0900, transfire@gmail.com writes:
Hmm, and you cannot use private methods in the subclass of OpenObject.
What should we do? Maybe you can define your own version of
BlankSlate that makes every required method into private, instead of
undef'ing it.
Yes!!! I had totally forgotten about that little trick with
method_missing catching public calls to otherwise private methods. Can
I always depend on Ruby working that way? If so I think it's all good.
#method_missing is and will be called when you invoke private methods
with the receiver specified.
I've somtimes wanted a way to get at the binding of the caller but
Binding.of_caller is just too much of a hack and I can't bring myself to
use it. But this would be a very elegant solution.
I'd prefer having the functionality built-in as well. It might happen in the next few years from what I understand.
any idea of the limitations of Binding.of_caller?
Well you can't use a trace function when you are using binding of caller, it has to be the last bit of code in a method that uses it, and it uses continuations (which are slow).
···
On Jul 4, 2006, at 10:52 AM, ara.t.howard@noaa.gov wrote:
On Tue, 4 Jul 2006, Florian Gross wrote:
-a
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama
It depends on a bug in Ruby (but that can be fixed as soon as that bug is fixed) and will only work 100% correctly if you are using it in a method that is called in the same context as its caller. For example breakpoint() is OK, but Breakpoint.breakpoint() will not give you the correct instance variables.
I don't think it is too slow. Not being able to restore previous trace funcs is another downside, however.
Perhaps it is time to write a C extension for this after all?
class A
def initialize
jump_up_and_down( ) # look, I'm calling a "function" (No explicit receiver)
end
private
def jump_up_and_down( )
...
end
end
That's why top level declared methods are private. It's to distinguish "function" methods from method methods. Hence the name "funcall" (call a "function")
···
On Jul 4, 2006, at 2:53 PM, dblack@wobblini.net wrote:
Can you show me an example? I'm still not understanding. I'm
thinking of:
obj.funcall(:meth)
but maybe there's a different/new syntax for funcall? Is it now a
top-level method?
At least, we seem to have converged on "send!".