On 7/11/07, [email protected] [email protected] wrote:
I suspect that if we didn’t have the ‘yield’ keyword and the process
of making a transition to having it be message-style, I don’t think
“yield” would ever show up as a suggestion for a name for this method
(though of course an astonishing number of terms show up in the
various free-for-all method-name suggestion fests
block.eigenyield #
martin
On 7/11/07, [email protected] [email protected] wrote:
The way I’ve always read the object.message syntax is that you’re saying
Doesn’t look like it
Too bad because I could not accept accept
Seriously, accept what, to be run?
Well if you native speakers think it is good, I will shut my mouth,
but it really sounds strange to me.
Robert
On Wed, Jul 11, 2007 at 06:08:12PM +0900, Martin DeMello wrote:
On 7/11/07, [email protected] [email protected] wrote:
I suspect that if we didn’t have the ‘yield’ keyword and the process
of making a transition to having it be message-style, I don’t think
“yield” would ever show up as a suggestion for a name for this method
(though of course an astonishing number of terms show up in the
various free-for-all method-name suggestion fests
block.eigenyield #
This may be a job for . . .
Eigeneigen!!!
On Jul 10, 4:36 pm, “ara.t.howard” [email protected] wrote:
‘doing my own thing…’
block.yield ‘control to you’
Hrm; nope, I’m with David. LET THE POLARIZATION BEGIN!
When you write:
foo.explode
you are saying:
“Tell the ‘foo’ object to ‘explode’.”
Thus, if you write:
blk.yield
you are saying:
“Tell the ‘blk’ object to ‘yield’.”
…which, as David pointed out, is backwards.
When you want to say “Now yield to the block” the imperative verb has
the implicit subject of “self”. The extension of this would be:
self.yield( blk )
which of course is just:
yield( blk )
Of course, in the current situation where there cannot be more than
one Blessed block, this can be optimized to infer the blessed block,
and we get back to the current:
yield
blk.call is (IMHO and by the rationale above) sort of in the same
boat. You are telling the interpreter to call the block; you are not
telling the block to call itself. More sensible, IMHO, would be:
blk.run
blk.execute
because those are verbs that the block should know how to do.
On Jul 11, 2:37 am, “Robert D.” [email protected] wrote:
Well if you native speakers think it is good, I will shut my mouth,
but it really sounds strange to me.
This native-English speaker concurs: “accept” is not at all a good
method name for a block/proc to say “please run yourself”. Better I
think is (as I already posted) “run”. It’s both short and
representative.
On Jul 11, 2007, at 8:50 AM, Phrogz wrote:
Seriously, accept what, to be run?
Well if you native speakers think it is good, I will shut my mouth,
but it really sounds strange to me.
This native-English speaker concurs: “accept” is not at all a good
method name for a block/proc to say “please run yourself”. Better I
think is (as I already posted) “run”. It’s both short and
representative.
Oh! I like run!! Proc#run()
What about do??? proc#do()
execute
perform
workon
attend
attendto
complete
On 7/11/07, Chad P. [email protected] wrote:
This may be a job for . . .
Eigeneigen!!!
Difficult to parse I know
Eigen*
R.
On 7/11/07, Phrogz [email protected] wrote:
This native-English speaker concurs: “accept” is not at all a good
method name for a block/proc to say “please run yourself”. Better I
think is (as I already posted) “run”. It’s both short and
representative.
I support my supporters
#run is great ( I can live with #call though, notwithstanding your
correct reasoning against it )
Robert
On 7/10/07, Yukihiro M. [email protected] wrote:
Hi,
I think we will lose great chance of optimization by making return,
break, etc. into methods.
matz.
Fair enough. (gosh-darned reality intruding on my fantasies again)
On 7/11/07, John J. [email protected] wrote:
Doesn’t look like it
Why are we just throwing aside the perfectly named method #call with
it’s alias to #[]? The pattern of naming methods #call for action
objects is getting more and more common, especially now that Rack uses
it. And it really does explain what is going on. I don’t think we
need that many more alias’ in Proc. I agree that Proc#yield is wonko,
and that yield should stay in the current incarnation, but why are we
all about losing Proc#call?