Undefining a method?

Ruby
1

Is it possible to undefine a method. For example:

class A
def method
end
end

A.undefine_method(:method)

Is this possible?

I need to do this because I’m dynamically building methods into a class
and it would make everything cleaner.

2

undef :method

irb(main):001:0> def cow
irb(main):002:1> p “cow”
irb(main):003:1> end
=> nil
irb(main):004:0> cow
“cow”
=> nil
irb(main):005:0> undef :cow
=> nil
irb(main):006:0> cow
NameError: undefined local variable or method `cow’ for main:Object
from (irb):6
irb(main):007:0>

Stephen B. IV

3

You have two choices:

  • undef_method
  • remove_method

The first prevents any and all calls to the passed in method; the
latter removes the method for just the given module which allows calls
to be made into the superclass.

See the docs: ri undef_method

4

Dear All …

which one is the most recomended for Install from SVN ?
Is it the “branch” or “Trunk” ?

And what is “tags” anyway ?

Sincerely
-bino-

5

bino_oetomo wrote:

Dear All …

which one is the most recomended for Install from SVN ?
Is it the “branch” or “Trunk” ?

And what is “tags” anyway ?

Sincerely
-bino-

Read here, you might know your answer:
http://eigenclass.org/hiki/bounded+space+instance_exec

6

On 4/15/07, bino_oetomo [email protected] wrote:

Dear All …

which one is the most recomended for Install from SVN ?
Is it the “branch” or “Trunk” ?

Typically, you want the code from ‘Trunk’. It’s the main development
‘branch’.

And what is “tags” anyway ?

The following is based on Pragmatic Version Control
http://www.pragmaticprogrammer.com/titles/svn/index.html

TAGS:

What are they?
A way to mark a static copy of set of files. The set of files can
come from various versions in your repository. Tags take up very
little room since they’re essentially just a set of pointers to
existing files/diffs.

When should I use them?
Use tags to mark releases. They give you a way to rebuild any given
release (in case a client deletes it, etc.). You can also use them to
check a release out to a branch for bug fixing, or adding new
features.

Anything else I should know?
If you need to edit the files, make a branch.

BRANCHES:

What are they?
As the name implies, it’s a branch from the main ‘Trunk’ dir (where
you do your core development). They allow you to run parallel
development where you can make minor changes and release the branch,
but continue full development on the trunk.

When should I use them?
Releases, experiments, bug fixes.

When you’re about to do a release, make a release branch, make any
changes that you don’t want in your ‘trunk’. When you actually
publish the code, you should tag it as a release

If you’re thinking about making massive changes, you can use a branch
for it. If you like the changes, merge them back into the trunk, if
not, keep them as a history, or kill them if you like.

When you get a bug report, make a new branch for tracking it. Tag it
before you do the fix, and tag it again after you’ve done the fix,
then merge the fix back into the trunk.

Anything else I should know?
Naming conventions are key. Here’s what the book suggests:

(forgive the formatting, or lack of it, gmail doesn’t use fix width
fonts)

Event Style Example Type *
Release Branch RB-rel RB-1.0 Branch
Releases REL-rel REL-1.0 Tag
Bug fix Branch BUG-track BUG-3035 Branch
Pre-bug fix PRE-track PRE-3035 Tag
Post-bug fix POST-track POST-3035 Tag
Experiments TRY-dev-desc TRY-no-db Branch

  • This is not in the book, it’s just my best guess of what they should
    be.

Sincerely
-bino-

hth