FAQ: Blocks, Procs, and Lambdas - Yielding With Parameters


#1

This community-built FAQ covers the “Yielding With Parameters” exercise from the lesson “Blocks, Procs, and Lambdas”.

Paths and Courses
This exercise can be found in the following Codecademy content:

Learn Ruby

FAQs on the exercise Yielding With Parameters

There are currently no frequently asked questions associated with this exercise – that’s where you come in! You can contribute to this section by offering your own questions, answers, or clarifications on this exercise. Ask or answer a question by clicking reply (reply) below.

If you’ve had an “aha” moment about the concepts, formatting, syntax, or anything else with this exercise, consider sharing those insights! Teaching others and answering their questions is one of the best ways to learn and stay sharp.

Join the Discussion. Help a fellow learner on their journey.

Ask or answer a question about this exercise by clicking reply (reply) below!

Agree with a comment or answer? Like (like) to up-vote the contribution!

Need broader help or resources? Head here.

Looking for motivation to keep learning? Join our wider discussions.

Learn more about how to use this guide.

Found a bug? Report it!

Have a question about your account or billing? Reach out to our customer support team!

None of the above? Find out where to ask other questions here!


#2

it says,

  1. On line 9, we call the yield_name method and supply the argument "Eric" for the name parameter. Since yield_name has a yield statement, we will also need to supply a block.

I don’t understand why “we will aslo need to supply a block”. thanks


#3

Then we yield to the block and pass in "Kim" .

Notice that the block in question is the one bound to the call with ‘Eric’ as the parameter? That’s why we need a block. We’re defering execution of the inline code until that block is finished running, with a different value for n. It’s the same block that will run to print Eric’s name when that time comes.

yield is unlike return in that it doesn’t lose it execution context, only segues from it to another context, and back again. It keeps its bearings and the method carries on as if nothing happened. Well, that’s my less than well informed take of it. A wiser, better informed member may pipe in to correct me, which we will both welcome if I’m wrong.