Forum: Ruby Undefining a method?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
328f0bb678423fcea01ebe3b0edc74e6?d=identicon&s=25 Ben Johnson (benjohnson)
on 2007-04-16 02:51
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.
Dedb38b3571b323b77bc9b221e940172?d=identicon&s=25 RubyTalk@gmail.com (Guest)
on 2007-04-16 03:05
(Received via mailing list)
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 Becker IV
8bc543795b502900b5333aea73ad5533?d=identicon&s=25 Eden Li (edenli)
on 2007-04-16 04:06
(Received via mailing list)
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
Df13d29fbc02d6979b4e6d3a3ccb4e4a?d=identicon&s=25 bino_oetomo (Guest)
on 2007-04-16 04:34
(Received via mailing list)
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-
F5bb435184cc39b6ef4847ed29cfdc46?d=identicon&s=25 Roseanne Zhang (roseanne)
on 2007-04-16 04:39
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
Ff63c03fd68754adbadd2c6314646bef?d=identicon&s=25 Bill Guindon (agorilla)
on 2007-04-16 04:58
(Received via mailing list)
On 4/15/07, bino_oetomo <bino@indoakses-online.com> 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
This topic is locked and can not be replied to.