探索元编程：《Metaprogramming.Ruby》读者评论揭示语言新边界

5星 · 超过95%的资源需积分: 10 7 浏览量更新于2024-07-31 收藏 6.36MB PDF 举报

"Metaprogramming.Ruby: Programming Like the Ruby Pros" 是一本深入探讨Ruby元编程的实用指南，它为那些已经熟悉Java编程的读者开启了一扇通向新思维的大门。作者将元编程的概念与Ruby语言的独特之处相结合，让读者在阅读过程中体验到如同使用Ruby进行创新开发的畅快感。书中强调，虽然Java本身提供了丰富的功能，但在处理某些高级任务时，如动态扩展、代码生成或领域特定语言（DSLs）的创建，元编程能力显得尤为关键。通过对比Java中的元编程与Ruby的相似性，作者指出在Ruby中运用元编程技术就如同手持一把短剑的勇士面对持有巨大武士刀的对手，能够以更灵活的方式解决问题。书中的内容不仅限于理论讲解，而是兼顾了实践应用。读者可以找到关于Ruby对象模型、闭包、DSL定义以及常见Gem库中元编程实例的清晰组织和详细解释。这些内容旨在帮助开发者理解并掌握如何通过元编程提升软件的效率和质量。然而，书中也提到一个转折点：当元编程知识深入骨髓后，使用传统的主流编程语言可能会感觉像是例行公事，因为它们缺乏Ruby这样的元编程灵活性。这提醒读者，在选择工具时要考虑长期的技术发展和个人兴趣。对于那些寻找元编程入门书籍的软件设计师和工程师来说，这本书是一个不可或缺的资源。Carlo Pecchia表示，他曾经在寻找合适的学习材料上费尽周折，但Metaprogramming.Ruby以其实际且易于理解的范例解决了他的困扰，证明了其价值。 "Metaprogramming.Ruby"是一本既能提供基础概念又能激发创新思维的教程，适合希望提升Ruby编程技能或者寻求元编程技术实战经验的开发者阅读，它将使读者在编程世界里如鱼得水，独树一帜。

THE “M” WORD 16

my_object.class # => Greeting

my_object.class.instance_methods(false) # => [:welcome]

my_object.instance_variables # => [:@text]

I asked my_object about its class, and it replied in no uncertain terms:

“

I’m a

Greeting.” Then I asked the class for a list of its instance methods.

(The false argument means, “List only instance methods you deﬁned

yourself, not those ones you inherited.”) The class answered with an

array containing a single method name: welcome( ). I also peeked into

the object itself, asking for its instance variables. Again, the object’s

reply was loud and clear. Since objects and classes ar e ﬁrst-class citi-

zens in Ruby, you can get a lot of information out of running code.

However, this is only half the picture. Sure, you can read language

constructs at runtime, but what about writing them? What if you want

to add new instance methods to Greeting, alongside welcome( ), while

he program is running? You might be wondering why on Earth anyone

would want to do that. Allow me to explain by telling a story.

The Story of Bob, Metaprogrammer

Bob, a Java coder who’s just starting to learn Ruby, has a grand plan:

he’ll write the biggest Internet social network ever for movie buffs. To do

that, he needs a database of movies and movie reviews. Bob makes it a

practice to write reusable code, so he decides to build a simple library

to persist objects in the database.

Bob’s First Attempt

Bob’s library maps each class to a database table and each object to

a record. When Bob creates an object or accesses its attributes, the

object generates a string of SQL and sends it to the database. All this

functionality is wrapped in a base class:

Download introduction/orm.rb

class Entity

attr_reader :table, :ident

def initialize(table, ident)

@table = table

@ident = ident

Database.sql

"INSERT INTO #{@table} (id) VALUES (#{@ident})"

end

def set(col, val)

atabase.sql

"UPDATE #{@table} SET #{col}='#{val}' WHERE id=#{@ident}"

end

THE “M” WORD 18

This code creates a new r ecord in movies, which has values 1, Doc-

tor Strangelove

, and Stanley Kubr ick for the ﬁelds id, title, and director,

respectively.

Proud of himself, Bob shows the code to his older, more experie

nced

colleague Bill. Bill stares at the screen for a few seconds and proceeds

to shatter Bob’s pride into tiny little pieces. “There’s a lot of duplicated

code here,” Bill says. “You have a

movies table with a title column in

the database, and you have a

Movie class with a @title ﬁeld in the code.

You also have a

title( ) method, a title=( ) method, and two "title" string

constants. You can solve this problem with way less code if you sprinkle

some metaprogramming magic over it.”

Enter Metaprogramming

At the suggestion of his expert-coder friend, Bob looks for a meta-

programming-based solution. He ﬁnds that very thing in the Active-

Record library, a popular Ruby library that maps objects to database

tables.

After a short tutorial, Bob is able to write the ActiveRecord ver-

ion of the

Movie class:

class Movie < ActiveRecord::Base

end

Yes, it’s as simple as that. Bob just subclassed the ActiveRecord::Base

class. He didn’t have to specify a table to map Movies to. Even better,

e didn’t have to write boring, almost identical methods such as

title( )

and

director( ). Everything just works:

movie = Movie.create

movie.title =

"Doctor Strangelove"

movie.title # => "Doctor Strangelove"

The previous code creates a Movie object that wraps a record in the

movies table, then accesses the record’s title ﬁeld by calling Movie#title( )

and Movie#title=( ). But these methods are nowhere to be found in the

ource code. How can title( ) and title=( ) exist, if they’re not deﬁned any-

where? You can ﬁnd out by looking at how ActiveRecord works.

The table name part is straightforward: ActiveRecord looks at the name

of the class through introspection and then applies some simple con-

1. You probably know this already, but it doesn’t hurt to refresh your memory: in Ruby,

movie.title = "Doctor Strangelove" is actually a disguised call to the title=( ) method—the same

as movie.title=("Doctor Strangelove").

2. ActiveRecord is part of Rails, the quintessential Ruby framework. You’ll read more

about Rails and ActiveRecord in Chapter 7, T

he Design of ActiveRecord, on page 190.

THE “M” WORD 19

ventions. Since the class is named Movie, ActiveRecord maps it to a

table named

movies. (This library knows how to ﬁnd plurals for English

words.)

What about methods like title=( ) and title( ), which access object attri-

utes (accessor methods for short)? This is where metaprogramming

comes in: Bob doesn’t have to write those methods. ActiveRecord de-

ﬁnes them automatically, after inferring their names from the database

schema. ActiveRecord::Base reads the schema at runtime, discovers that

the

movies table has two columns named title and director, and deﬁnes

accessor methods for two attributes of the same name. This means that

ActiveRecord deﬁnes methods such as Movie#title( ) and Movie#director=( )

out of thin air while the program runs!

This is the “yang” to the introspection “yin”: rather than just re

ading

from the language constructs, you’r e writing into them. If you think

this is an extremely powerful feature, well, you would be right.

The “M” Word Again

Now you have a more formal deﬁnition of metaprogramming:

Metaprogramming is writing code that manipulates language constructs

at runtime.

How did the authors of ActiveRecord apply this concept? Instead of

writing accessor methods for each class’s attributes, they wrote code

that deﬁnes those methods at runtime for any class that inherits from

ActiveRecord::Base. This is what I meant when I talked about “writing

ode that writes code.”

You might think that this is exotic, seldom-used stuff, but if you look

at Ruby, as we’re about to do, you’ll see that it’s used all around the

place.

Metaprogramming and Ruby

Remember our earlier talk about ghost towns and marketplaces? If you

ant to “manipulate language constructs,” those constructs must exist

at runtime. In this respect, some languages are deﬁnitely better than

others. Take a quick glance at a few languages and how much control

they give you at runtime.

3. The real implementation of accessors in ActiveRecord is a bit more subtle than I

describe here, as you’ll see in Chapter 8, I

nside ActiveRecord, on page 206.

THE “M” WORD 20

A program written in C spans two different worlds: compile time, where

you have language constructs such as variables and functions, and

runtime, where you just have a bunch of machine code. Since most

information from compile time is lost at runtime, C doesn’t support

metaprogramming or introspection. In C++, some language constructs

do survive compilation, and that’s why you can ask a C++ object for its

class. In Java, the distinction between compile time and runtime is even

fuzzier. You have enough introspection available to list the methods of

a class or climb up a chain of superclasses.

Ruby is arguably the most metaprogramming-friendly of the current

fashionable languages. It has no compile time at all, and most con-

structs in a Ruby program are available at runtime. You don’t come up

against a brick wall dividing the code that you’re writing from the code

that your computer executes when you run the program. There is just

one world.

In this one world, metaprogramming is everywhere. In fact, metapro-

gramming is so deeply entrenched in the Ruby language that it’s not

even sharply separated from “regular” programming. You can’t look at

a Ruby program and say, “This part here is metaprogramming, while

this other part is not.” In a sense, metaprogramming is a routine part

of every Ruby programmer’s job.

To be clear, metaprogramming isn’t an obscure art reserved for Ruby

gurus, and it’s also not a bolt-on power feature that’s useful only for

building something as sophisticated as ActiveRecord. If you want to

take the path to advanced Ruby coding, you’ll ﬁnd metaprogramming

at every step. Even if you’re happy with the amount of Ruby you already

know and use, you’re still likely to stumble on metaprogramming in

your coding travels: in the source of popular frameworks, in your fa-

vorite library, and even in small examples from random blogs. Until

you master metaprogramming, you won’t be able to tap into the full

power of the Ruby language.

There is also another, less obvious reason why you might want to learn

metaprogramming. As simple as Ruby looks at ﬁrst, you can quickly

become overwhelmed by its subtleties. Sooner or later, you’ll be ask-

ing yourself questions such as “Can an object call a private method on

other object of the same class?” or “How can you deﬁne class meth-

ods by importing a module?” Ultimately, all of Ruby’s seemingly compli-

cated behaviors derive from a few simple rules. Through metaprogram-

剩余281页未读，继续阅读

p_ppppppppp

粉丝: 0
资源: 60

探索元编程：《Metaprogramming.Ruby》读者评论揭示语言新边界

Metaprogramming Ruby 2nd Edition ruby元编程

MetaprogrammingRuby2ndEditionFreePdfBook.pdf 英文原版

Pragmatic.Metaprogramming.Ruby.Feb.2010.rar

c++11 auto

std::void_t

自定义generate pojos.groovy

groovy语法手册

Constant expression required

JavaScript groovy关系

qml 报错C4430

最新资源