Auto assign arguments?

From: “Bill K.” [email protected]

instance = MyClass.new(5)
#results in an instance variable @a with a value of 5

As I recall, this was proposed on this list several years ago.

Found it… Wow, that was awhile ago.

http://groups.google.com/group/comp.lang.ruby/browse_frm/thread/18465d51fb34fb98/4a0a63976cbe3ea9

HTH,

Bill

Wow. You guys are all coming up w/ great alternatives, but would
somebody please just answer my question? I am not asking for ways to
do what I want. I’m asking if you think the following proposed syntax
addition would be useful:

Any parameter preceded by a @ results in an instance variable being
created and initialized with the submitted value. So:

class MyClass
def initialize(@a)
end
end

instance = MyClass.new(5)
#results in an instance variable @a with a value of 5

This would apply to any parameter in the list, including those with
default values.

MyClass
def initialize(@a, @b=3)
end
end

instance = MyClass.new(5)
#results in an instance @a = 5 and @b = 3

instance = MyClass.new(5, 4)
#results in an instance @a = 5 and @b = 4

Does this seem like a good thing to propose?

Thank you,
David

David C.:

One thing I’d love to see in a future version of ruby is this;

def initialize(@thing, @other)
end

Try the following. Note that it does not actually set @thing and @other

  • they are only accessible methodically - but gives you an appropriate
    #initialize.

Klass = Struct.new(:thing, :other)
class Klass

more

end

Kalman

On 1/18/07, [email protected] [email protected] wrote:

One thing I’d love to see in a future version of ruby is this;

require ‘attributes’

harp:~ > ruby a.rb
#<C:0xb74c1b44 @c=2, @b=1, @a=0>

Thanks for all the responses, but I’m really looking for something
that feels simple and explicit (these suggestions all feel a little
magical and confusing).

Do any of you think this would be a good or bad thing to add to the
language? I’d like to post an RCR, but the RCRchive warns against
poorly researched requests - so I’d like to do some research :wink: My
feeling is that my proposal would add a very simple and explicit means
of assigning those args that you wish to assign. What’s yours?

Thanks,
David

On 1/19/07, Yukihiro M. [email protected] wrote:

| define_method :initialize do |@a| ; end
effective only inside the block).

                                                    matz.

That is your decision of course and by disallowing the above code we
are
much more consistent again. (so I feel it is a good decision too :wink:
Personally I would have preferred that both were allowed but it is not
really a big deal.

In that context it would be nonsense to file an RCR as mentioned above.
Thanx for clarifying.

Cheers
Robert

P.S.
I should definitely get ruby1.9 fast and run my code on it before
posting it
:frowning:
Sorry folks
R.

On 1/19/07, David C. [email protected] wrote:

Wow. You guys are all coming up w/ great alternatives, but would
somebody please just answer my question? I am not asking for ways to
do what I want. I’m asking if you think the following proposed syntax
addition would be useful:

Your idea is intriguing
you can already do

proc{ |@a| }.call(42)

so why not allow instance methods as formal parameters for methods?
By no means such a construct should be reduced to #initialize it should
be
legal for every method of course.
Now I am not qualified to talk about impacts or implementation details.
Given that so many people have already implemented this it seems a
desired
features.
I would vote “in favour” maybe even “strongly in favour” for such a RCR.
I
will listen to wiser guys before voting though.

Cheers
Robert

Any parameter preceded by a @ results in an instance variable being

This would apply to any parameter in the list, including those with
instance = MyClass.new(5, 4)
#results in an instance @a = 5 and @b = 4

Does this seem like a good thing to propose?

See above for any method of course.

Thank you,

David

Cheers
Robert

On 1/18/07, James Edward G. II [email protected] wrote:

I would really be against that. If you do that, there’s no point in
how Ruby currently has all instance data as private. It blows
encapsulation wide open and being very against the spirit of OO just
doesn’t feel Rubyish to me.

+1,

BUT… it’s be okay if you could build this as a module, I think.
Then you could just include it in a class to get the behavior when it
is appropriate.

On 18.01.2007 21:25, Kalman N. wrote:

Klass = Struct.new(:thing, :other)
class Klass

more

end

You can even do

Klass = Struct.new :foo, :bar do
def some_method
end
end

which I find pretty nice. :slight_smile:

robert

On 1/19/07, Yukihiro M. [email protected] wrote:

names) can be seen as part of class API. Allowing instance variables
as formal arguments seems like disclosing the internal issues.

Yes exactly but by explicit declaration, so

    def set_length(@length)

just would be a willful disclosure a little bit like
attr_writer :length

But your reasoning is sound of course I feel it more important is the
unification of
method and block parameter behaviour which you have achieved in 1.9.

It would be interesting why you allowed instance variables in blocks,
maybe
because blocks are
not exposing an API?
I am confusing myself :wink:

Finally, I admit that the code like this

but I feel the intention of the latter code is far clearer than the
former.

I agree the first is a little bit against POLS, I do not know any other
language where you can
define instance variables as formal parameters.
I am sure someone will fill this gap quickly though :wink:

                                                    matz.

Cheers
Robert

Hi,

In message “Re: auto assign arguments?”
on Fri, 19 Jan 2007 22:15:33 +0900, “Robert D.”
[email protected] writes:
|Right now you can already write code like this
|
|class B
| attr_reader :a
| define_method :initialize do |@a| ; end
|end

|I feel that this is worth another shot, maybe Matz could tell us to stop
|working on this if he really does not like it.
|It seems reasonable to assume that the reasons he had to reject the RCR do
|not exist anymore or that he has changed his mind, no?

I haven’t changed my mind (yet). And I even disallowed above code in
1.9. Block parameters should only be local variables (and they are
effective only inside the block).

          matz.

On Jan 18, 2007, at 5:06 PM, Gregory B. wrote:

BUT… it’s be okay if you could build this as a module, I think.
Then you could just include it in a class to get the behavior when it
is appropriate.

The code below uses instance_exec from ruby 1.9. It will still work
under ruby 1.8 as long as you don’t give a block to the #init method.

Gary W.

module Init
def init(*syms, &iproc)
define_method(:initialize) {|*x|
raise ArgumentError, “wrong number of arguments: #{x.size} for
#{syms.size}” if x.size != syms.size
syms.zip(x).each { |sym, val|
instance_variable_set("@#{sym}", val)
}
instance_exec(*x, &iproc) if iproc
}
end
end

class A
extend Init
init :a, :b, :c, :d
end

a = A.new(1,2,3,4)
p a.instance_variables # ["@b", “@a”, “@c”, “@d”]
a.instance_variables.each { |n|
puts “#{n} = #{a.instance_variable_get(n)}”
}

class Object
extend Init
end

class B
attr :attr1, :attr2
init :attr1, :attr2
end

b = B.new(‘foo’, ‘bar’)
p b.attr1 # ‘foo’
p b.attr2 # ‘bar’

class C
init :c, :d do
puts “@c is #{@c}”
puts “@d is #{@d}”
end
end

C.new(3,4) # @c is 3
# @d is 4
begin
C.new(5) # argument error
rescue
p $!
end

On 1/19/07, Yukihiro M. [email protected] wrote:

former.
Very helpful. Thanks for the clarification.

Cheers,
David

On 1/18/07, Daniel DeLorme [email protected] wrote:

def initialize(v = nil)

C.new(54).ultimate #=> 54
Hmm… you’re right. I can see that now (and have used it!)

Still, I do think the RCR would make things more messy, but would be
all for something in core or the standard library that could allow me
to enable the behavior on the fly for any given class.

(Though I’m not strongly invested one way or the other)

Hi,

In message “Re: auto assign arguments?”
on Sat, 20 Jan 2007 15:26:59 +0900, Daniel DeLorme
[email protected] writes:

|That’s interesting. Would you mind sharing your insight on why these should be
|separated?

I attached the code snippet to the last post. If it doesn’t appeal
you, I don’t think I can express it more clearly. I like usefulness
in Ruby, but too much implicit behavior makes our programs into
puzzles. It’s matter of balance.

          matz.

On 1/19/07, [email protected] [email protected] wrote:

Any parameter preceded by a @ results in an instance variable being
That was proposed as an RCR and rejected; see
A. Ruby Power and Light, LLC (http://www.rubypal.com)

It was rejected more than 5 years ago and without any reason. The RCR
was
very short. I feel that this could be presented again, be motivated much
better (e.g. indicating that instance variables can be block parameters)
etc.etc.

Right now you can already write code like this

class B
attr_reader :a
define_method :initialize do |@a| ; end
end
b=B.new 42
b.a => 42

I feel that this is worth another shot, maybe Matz could tell us to stop
working on this if he really does not like it.
It seems reasonable to assume that the reasons he had to reject the RCR
do
not exist anymore or that he has changed his mind, no?

Cheers
Robert

Hi –

On Fri, 19 Jan 2007, David C. wrote:

end
end

instance = MyClass.new(5)
#results in an instance variable @a with a value of 5

That was proposed as an RCR and rejected; see
http://oldrcrs.rubypal.com/rejected.html#rcr3

David

Gregory B. wrote:

On 1/18/07, David C. [email protected] wrote:

Does this seem like a good thing to propose?

-1. I see @a and @b to be part of the classe’s instance variables, so

Why the class’ instance variables? That doesn’t fit with the current
pattern:

class C
def initialize(v = nil)
@default = v
end
def otherdefault
42
end
def ultimate(v = @default || otherdefault)
v
end
end
C.new.ultimate #=> 42
C.new(54).ultimate #=> 54

If an object’s instance variables (and even methods) can be used as
default
values, it would be coherent to also allow them in the argument list.
This feels
100% instinctive to me.

+1

-dd

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs