[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

nested methods good or bad design

John Maclean

6/30/2008 3:43:00 PM

=begin
Hey chaps,

Is it bad practice to have nested methods? I'm sure that it would
result in messey/cluttered code. Does any one actually code like that
at all? Not really -essential- as everything is working, (even better
than), as expected without nested methods. Just would be nice to know
what the gurus andmy peers think on this one.

- jjm
=end

class Foo
def initialize(this, that, the_other)
@this = this
..
end

def method_1?
# here I check for some criteria
if %x[some_command] == "some criteria"
@this = true
end

# every other method from here on depends on @this == true. Would be nice to be able to skip the remained of the code if @this != true

def method_2
# do all of this stuff if @this = true
end





14 Answers

ara.t.howard

6/30/2008 4:19:00 PM

0


On Jun 30, 2008, at 9:42 AM, John Maclean wrote:

> def method_1?
> # here I check for some criteria
> if %x[some_command] == "some criteria"
> @this = true
> end
>
> # every other method from here on depends on @this == true. Would
> be nice to be able to skip the remained of the code if @this != true
>
> def method_2
> # do all of this stuff if @this = true
> end

this is *exactly* what closures are for

def method_1
method_2 = @this ? lambda{ p 'yup' } : lambda{ p 'nope' }
method_3 = @this ? lambda{ p 'a' } : lambda{ p 'b' }

method_2.call
method_3.call

regards.

a @ http://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama




Charles Oliver Nutter

7/1/2008 1:12:00 PM

0

John Maclean wrote:
> =begin
> Hey chaps,
>
> Is it bad practice to have nested methods? I'm sure that it would
> result in messey/cluttered code. Does any one actually code like that
> at all? Not really -essential- as everything is working, (even better
> than), as expected without nested methods. Just would be nice to know
> what the gurus andmy peers think on this one.
>
> - jjm
> =end
>
> class Foo
> def initialize(this, that, the_other)
> @this = this
> ..
> end
>
> def method_1?
> # here I check for some criteria
> if %x[some_command] == "some criteria"
> @this = true
> end
>
> # every other method from here on depends on @this == true. Would be nice to be able to skip the remained of the code if @this != true
>
> def method_2
> # do all of this stuff if @this = true
> end

If you intend to skip defining those other methods, you need a state
variable (constant, class var, whatever) that has a lifespan longer than
that of the instances of your class. @this is going to be nil until set
by method_1?, which can only be called against an instance of Foo, which
can only happen after Foo has already been defined along with the
methods in Foo. But you can put such logic in the Foo class object to
achieve the effect you're looking for:

class Foo
class << self
def method_1?
# here I check for some criteria
if %x[some_command] == "some criteria"
true
else
false
end
end
end

if method_1?
def method_2
# etc
end
end
end

method_2 will only be defined if your criteria is met.

- Charlie


Charles Oliver Nutter

7/1/2008 1:14:00 PM

0

ara.t.howard wrote:
> this is *exactly* what closures are for
>
> def method_1
> method_2 = @this ? lambda{ p 'yup' } : lambda{ p 'nope' }
> method_3 = @this ? lambda{ p 'a' } : lambda{ p 'b' }
>
> method_2.call
> method_3.call

method_2 and method_3 are not long-lived, so if OP intention was to
conditionally define methods, closures are a rather orthogonal concept.

- Charlie

krusty.ar@gmail.com

7/1/2008 7:28:00 PM

0

On Jun 30, 12:42 pm, John Maclean <jaye...@gmail.com> wrote:
> =begin
> Hey chaps,
>
> Is it bad practice to have nested methods? I'm sure that it would
> result in messey/cluttered code. Does any one actually code like that
> at all? Not really -essential- as everything is working, (even better
> than), as expected without nested methods. Just would be nice to know
> what the gurus andmy peers think on this one.
>

I'm not sure I understand completely, but how is having a variable (or
any other object) laying around representing that the system can call
method2 is cleaner than:

def method1
if criteria
def method 2
##...
end
end
end

?

I find that easier to follow than:

def method1
if criteria
#set some flag
end
end

##.. more code

##check the flag

def method2
##...
end

The only way that the first alternative could get messy is with very
long methods, wich you should avoid anyway.

Lucas.


ThoML

7/1/2008 8:18:00 PM

0

> Is it bad practice to have nested methods?

Like Eiffel, Smalltalk, Java, Ruby doesn't have nested methods
unlike ... uhm, Python, Scheme etc. (Everything IIRC and AFAIK which
doesn't mean much ATM. :)

Example:

def a
def b
p 1
end
b
end

a
=> 1
b
=> 1

a and b are defined at the same level. This trick can be used to
dynamically (re)define methods at runtime and can be handy at times.

You could create a normal method and make that private.

krusty.ar@gmail.com

7/1/2008 8:38:00 PM

0

On Jul 1, 5:17 pm, ThoML <micat...@gmail.com> wrote:

>
> def a
>     def b
>         p 1
>     end
>     b
> end
>
> a
> => 1
> b
> => 1
>

But this has the additional (somewhat usefull) effect that calling b
before a will give an error. Maybe I'm not understanding what you are
reffering to as nested methods or "same level", what can you do in
phyton or scheme that behaves different from this?

Lucas.

Lucas.

ThoML

7/2/2008 3:49:00 AM

0

> Maybe I'm not understanding what you are
> reffering to as nested methods or "same level", what can you do in
> phyton or scheme that behaves different from this?

>>> def a():
.... def b():
.... print(1)
.... b()
....
>>> a()
1
>>> b()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'b' is not defined

b() is not accessible from outside of a().

ara.t.howard

7/2/2008 4:01:00 AM

0


On Jul 1, 2008, at 9:47 PM, ThoML wrote:

> b() is not accessible from outside of a().


you have to execute it to make the definition occur, after that it is:


cfp:~ > cat a.rb
def a
def b
42
end
end

p a
p b



cfp:~ > ruby a.rb
nil
42


a @ http://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama




ThoML

7/2/2008 6:07:00 AM

0

> > b() is not accessible from outside of a().
>
> you have to execute it to make the definition occur

This referred to the Python counter example -- because KA asked how
Python/Scheme/... are different in this respect.

krusty.ar@gmail.com

7/2/2008 1:18:00 PM

0

On Jul 2, 12:49 am, ThoML <micat...@gmail.com> wrote:
> > Maybe I'm not understanding what you are
> > reffering to as nested methods or "same level", what can you do in
> > phyton or scheme that behaves different from this?
> >>> def a():
>
> ...     def b():
> ...         print(1)
> ...     b()
> ...>>> a()
> 1
> >>> b()
>
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> NameError: name 'b' is not defined
>
> b() is not accessible from outside of a().

Y get it, it's as if each method defines a namespace, can
youdosomething like a()::b() from ouside a?

Lucas.