Afrikaans
Akan
Albanian
Amharic
Arabic
Armenian
Azerbaijani
Basque
Belarusian
Bemba
Bengali
Bihari
Bosnian
Breton
Bulgarian
Cambodian
Catalan
Cebuano
Cherokee
Chichewa
Chinese (Traditional)
Corsican
Croatian
Czech
Danish
Dutch
English
Esperanto
Estonian
Ewe
Faroese
Filipino
Finnish
French
Frisian
Ga
Galician
Georgian
German
Greek
Guarani
Gujarati
Haitian Creole
Hausa
Hawaiian
Hebrew
Hindi
Hmong
Hungarian
Icelandic
Igbo
Indonesian
Interlingua
Irish
Italian
Japanese
Javanese
Kannada
Kazakh
Kinyarwanda
Kirundi
Kongo
Korean
Krio (Sierra Leone)
Kurdish
Kurdish (Soranî)
Kyrgyz
Laothian
Latin
Latvian
Lingala
Lithuanian
Lozi
Luganda
Luo
Luxembourgish
Macedonian
Malagasy
Malay
Malayalam
Maltese
Maori
Marathi
Mauritian Creole
Moldavian
Mongolian
Myanmar (Burmese)
Montenegrin
Nepali
Nigerian Pidgin
Northern Sotho
Norwegian
Norwegian (Nynorsk)
Occitan
Oriya
Oromo
Pashto
Persian
Polish
Portuguese (Brazil)
Portuguese (Portugal)
Punjabi
Quechua
Romanian
Romansh
Runyakitara
Russian
Samoan
Scots Gaelic
Serbian
Serbo-Croatian
Sesotho
Setswana
Seychellois Creole
Shona
Sindhi
Sinhalese
Slovak
Slovenian
Somali
Spanish
Spanish (Latin American)
Sundanese
Swahili
Swedish
Tajik
Tamil
Tatar
Telugu
Thai
Tigrinya
Tonga
Tshiluba
Tumbuka
Turkish
Turkmen
Twi
Uighur
Ukrainian
Urdu
Uzbek
Vietnamese
Welsh
Wolof
Xhosa
Yiddish
Yoruba
Zulu
We're not going to look at another block pattern that turns up in a very unexpected place.
If you've ever written a Ruby gem, then you might have seen something like this.
So we're creating a Ruby gem specification here using the specification class that's
inside of the gem module, but notice we're calling new to initialize a new object,
but the new method takes a block here.
The block parameter is S, that's the specification object that's being initialized or
created, and then inside of the block, we can just assign values to some of the attributes
of the specification.
In this particular case, I've all signed the result of all this to the spec object,
and then printed it out down below.
And if we run this, well, the 2S method in the gem spec class, it just prints out the name,
in this case it'd be my gem, and the version is 2.0.0, which is what we set up in the
block.
And the block, in this case, gives us a way to set up that object inside of a block structure
here.
So how does this work?
Well, let's try writing our own shorter version of this.
I'm going to abbreviate this a little bit because we don't need all these attributes,
right?
And because gem, the gem module, on the specification class, they've already been written,
and they're actually loaded in the Ruby programs, I'm going to change this around.
Our modules are going to be called gem with a j, and that way we won't run into any collisions
with the built-in specification class in RubyJems.
All right, let's go ahead and implement this.
We'll do it right up here.
We're going to have a module, it's called gem with a j, inside of there, we're going to have
a class called specification.
It has some attributes.
We'll have extra accessors for those.
We have name, version, and summary.
And then we have an initialized method.
Now remember, when you call new and Ruby to create a new object, new allocates the memory,
but then behind the scenes that turns around and calls the initialized method to actually
initialize that object.
So in the initialized method, we generally set attributes.
In this case, we can set the version attribute to be by default 1.0.0.
All right?
And you might do more default initialization right here, as you would, any initialized method.
But we know that this new method, we passed the block to that, and it could do some more
initialization.
So how do we pull that off?
Well, inside of our initialized method here, we just yield to the block.
We need to give it the object that's being created, which is the specification object
in this case.
We can get that by using self, inside of initialize, self is the object we're initializing.
And we only want to do that if a block was given.
So we use block underscore given, question mark there.
All right, we save that and run it.
Well now it prints out our gems specification.
I want to see what the attributes are in there.
So when it changes a little bit, I'm going to use our old friend P right there to print
out its native form.
And we see we've got a gems specification object whose version is 2.0.
Notice it's not 1.0 as up in here, because our block overwrote that version number
right here.
So our block did further initialization.
This name is my gem and the summary is, this is a cool gem.
So this block based style makes it very clear that inside of the block, all the statements
in that block are focusing on initializing this same object.
So what if we don't pass it up block?
Well we're checking if a block is given.
So we should be okay there.
If we take this block and I'm just going to comment that out right there.
So we don't have it associated.
And then we can initialize attributes as we normally were with an object say I'm going
to set the name of our gem to be something like Mike.
Well that should still work and it does.
But notice that the version now is 1.0.0 because that's the default version and the name
is now Mike.
So because we use the block given, we can associate a block or not associate a block.
So whether you want to use a block or not is really a stylistic design decision.
You can assign attributes as you normally would like this or if you want to make it very
clear that this chunk of code is all focused on initializing the object then you can
pass a block in there.
So when I was researching code for this course I was surprised how often I found this block
initialization pattern in the wild and you'll see a lot more examples of this in the exercise.
In the next section we're going to look at the final use for blocks and it's a great way
to manage resources.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.