What is the usefulness of using only greedy operator as the argument in method parameter list?

Ruby
1

Hi,

From the Rspec doco, I found one code :-

https://www.relishapp.com/rspec/rspec-core/v/3-0/docs/subject/implicitly-defined-subject#`subject`-in-a-nested-group-with-a-different-class-(innermost-wins)

class ArrayWithOneElement < Array
def initialize(*)
super
unshift “first element”
end
end

Here the #initialize method will never throw argument error as greedy

  • will
    swallow whatever you will give it. And if you don’t give it anything, it
    wouldn’t cry also.

My question is what is the advantage of this pattern of method
argument
signature ? While I don’t need any argument while instantiating a class,
I
could define it,

def initialize()
end

If I need argument at the time of instantiation, I will mention it
properly
there -

def initialize(arg1,arg2) # whatever pattern fits
end

But why this greedy approach, while I wouldn’t be able to access it
any of
the argument what may be passed or not ?

Can anyone highlight me on this ?

–

Regards,
Arup R.

Debugging is twice as hard as writing the code in the first place.
Therefore,
if you write the code as cleverly as possible, you are, by definition,
not
smart enough to debug it.

–Brian Kernighan

2

On Tue, Jul 1, 2014 at 4:28 PM, Arup R.
[email protected] wrote:

class ArrayWithOneElement < Array
def initialize(*)
super
unshift “first element”
end
end

Here the #initialize method will never throw argument error as greedy * will
swallow whatever you will give it. And if you don’t give it anything, it
wouldn’t cry also.

But why this greedy approach, while I wouldn’t be able to access it any of
the argument what may be passed or not ?

Can anyone highlight me on this ?

You make your class robust against super class #initialize changes.
The matter is probably more important for a module. I mentioned that a
long time ago in our now deserted blog:
http://blog.rubybestpractices.com/posts/rklemme/018-Complete_Class.html

If your module needs initialization code then this is the way to do it

  • otherwise you cannot insert it into arbitrary class hierarchies.

Kind regards

robert

3

But why this greedy approach, while I wouldn’t be able to access it any of
the argument what may be passed or not ?

You wouldn’t be able to access it, but your ‘super’ friend will be.

class Father
def initialize(*args)
puts “From Father, args were #{args.inspect}”
end
end

class Son < Father
def initialize(*)
# I don’t have any reference to the args.
# But my ‘super’ friend has
super
end
end

Son.new
Son.new “a”, “b”, “c”, 1, :two, [3, 4], five: 5, six: 6, seven: 7

Great post Robert K.!

[From Robert post]
“While we’re at it: if you write a module which is intended as mixin
and needs initialization itself the initializer should simply pass on
all arguments in order to be compatible with arbitrary inheritance
chains:”

module AnotherMixin

Prepare internal state and pass on all

arguments to the super class

def initialize(*a, &b)
super
@list = []
end
end

Abinoam Jr.

4

On Tuesday, July 01, 2014 12:58:30 PM Abinoam Jr. wrote:

arguments to the super class

def initialize(*a, &b)
super
@list = []
end
end

Abinoam Jr.

+1 to you and Robert both. Thanks for the detail answer. :slight_smile:

–

Regards,
Arup R.

Debugging is twice as hard as writing the code in the first place.
Therefore,
if you write the code as cleverly as possible, you are, by definition,
not
smart enough to debug it.

–Brian Kernighan