Yield should be renamed call_block

[Robert Dober]

On 7/11/07, dblack@... <dblack@...> wrote:

> Hi --
>
> On Wed, 11 Jul 2007, Chad Perrin wrote:
>
> > On Wed, Jul 11, 2007 at 09:28:14AM +0900, dblack@... wrote:
> >>
> >> On Wed, 11 Jul 2007, Chad Perrin wrote:
> >>> On Wed, Jul 11, 2007 at 07:36:34AM +0900, ara.t.howard wrote:
> >>>>
> >>>> i'm with matz on this one
> >>>>
> >>>>  block.yield
> >>>>
> >>>> reads, to me, simple as
> >>>>
> >>>>  'doing my own thing...'
> >>>>
> >>>>  block.yield 'control to you'
> >>>
> >>> Speaking more generally . . .
> >>>
> >>> The way I've always read the object.message syntax is that you're saying
> >>> something like "Hey, Object!  I want you to [yield]."  Substitute the
> >>> particular message you're sending for [yield] as necessary.
> >>
> >> Exactly -- blocks don't yield, so let's not ask them to :-)
> >
> > Is the word "accept" being used for anything?
>
> $ ri Proc#accept
> Nothing known about Proc#accept
>
> 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

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

[Martin DeMello]

On 7/11/07, dblack@... <dblack@...> 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

[Chad Perrin]

On Wed, Jul 11, 2007 at 06:08:12PM +0900, Martin DeMello wrote:
> On 7/11/07, dblack@... <dblack@...> 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!!!

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Rudy Giuliani: "You have free speech so I can be heard."

[Robert Dober]

On 7/11/07, Chad Perrin <perrin@...> wrote:

> On Wed, Jul 11, 2007 at 06:08:12PM +0900, Martin DeMello wrote:
> > On 7/11/07, dblack@... <dblack@...> 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!!!

Difficult to parse I know ;)
Eigen*
R.
--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

[Phrogz-3]

On Jul 10, 4:36 pm, "ara.t.howard" <ara.t.how...@...> wrote:

> On Jul 10, 2007, at 3:33 PM, dbl...@... wrote:
> > Vagueness would be OK, maybe, but the problem is bigger than that:
> > it's that "block.yield" just doesn't express what's happening.
>
> i'm with matz on this one
>
>    block.yield
>
> reads, to me, simple as
>
>    '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.

[Phrogz-3]

On Jul 11, 2:37 am, "Robert Dober" <robert.do...@...> wrote:

> On 7/11/07, dbl...@... <dbl...@...> wrote:
> > On Wed, 11 Jul 2007, Chad Perrin wrote:
> > > Is the word "accept" being used for anything?
> > $ ri Proc#accept
> > Nothing known about Proc#accept
>
> > 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.

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.

[John Joyce]

On Jul 11, 2007, at 8:50 AM, Phrogz wrote:

> On Jul 11, 2:37 am, "Robert Dober" <robert.do...@...> wrote:
>> On 7/11/07, dbl...@... <dbl...@...> wrote:
>>> On Wed, 11 Jul 2007, Chad Perrin wrote:
>>>> Is the word "accept" being used for anything?
>>> $ ri Proc#accept
>>> Nothing known about Proc#accept
>>
>>> 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.
>
> 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

[Chris Carter-2]

On 7/11/07, John Joyce <dangerwillrobinsondanger@...> wrote:

>
> On Jul 11, 2007, at 8:50 AM, Phrogz wrote:
>
> > On Jul 11, 2:37 am, "Robert Dober" <robert.do...@...> wrote:
> >> On 7/11/07, dbl...@... <dbl...@...> wrote:
> >>> On Wed, 11 Jul 2007, Chad Perrin wrote:
> >>>> Is the word "accept" being used for anything?
> >>> $ ri Proc#accept
> >>> Nothing known about Proc#accept
> >>
> >>> 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.
> >
> > 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
>
>

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?


--
Chris Carter
concentrationstudios.com
brynmawrcs.com

[Robert Dober]

On 7/11/07, Phrogz <phrogz@...> wrote:
<snip>
>
> 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

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

[Logan Capaldo]

On 7/10/07, Yukihiro Matsumoto <matz@...> 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)