[lnkForumImage]
TotalShareware - Download Free Software

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


 

Forums >

comp.lang.ruby

auto assign arguments?

David Chelimsky

1/18/2007 8:13:00 PM

I see where to put bugs and patches, but this is a feature request. Is
this the right place to submit these?

In any case, here's a feature request:

I find that I do a lot of this:

def initialize(thing, other)
@thing = thing
@other = other
end

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

def initialize(@thing, @other)
end

... and have that automagically initialize @thing and @other with the
submitted values.

Thanks,
David

22 Answers

Kalman Noel

1/18/2007 8:26:00 PM

0

David Chelimsky:
> 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

Gary Wright

1/18/2007 8:42:00 PM

0


On Jan 18, 2007, at 3:13 PM, David Chelimsky wrote:
> One thing I'd love to see in a future version of ruby is this;
>
> def initialize(@thing, @other)
> end

Well, you can get pretty close...

def initialize(*a)
@thing, @other = *a
end

You don't get method arity checking that way but...

def initialize(a,b)
@thing, @other = a,b
end

isn't too bad either.

As for as official change requests see: http://rcr...

Gary Wright




James Gray

1/18/2007 8:55:00 PM

0

On Jan 18, 2007, at 2:13 PM, David Chelimsky wrote:

> I see where to put bugs and patches, but this is a feature request. Is
> this the right place to submit these?
>
> In any case, here's a feature request:
>
> I find that I do a lot of this:
>
> def initialize(thing, other)
> @thing = thing
> @other = other
> end
>
> One thing I'd love to see in a future version of ruby is this;
>
> def initialize(@thing, @other)
> end
>
> ... and have that automagically initialize @thing and @other with the
> submitted values.

Some thinking-out-loud:

#!/usr/bin/env ruby -w

class Module
def constructor(*attrs)
define_method(:initialize) do |*passed|
raise ArgumentError, "Wrong number of arguments" unless attrs.size == passed.size

attrs.each_with_index do |att, i|
instance_variable_set("@#{att}", passed[i])
end

after_initialize if respond_to? :after_initialize
end
end
end

class ABC
constructor :a, :b, :c

def after_initialize
p instance_variables.map { |var| [var, instance_variable_get
(var)] }.sort
end
end

ABC.new(1, :two, "three")
ABC.new(*%w[testing my code])
# >> [["@a", 1], ["@b", :two], ["@c", "three"]]
# >> [["@a", "testing"], ["@b", "my"], ["@c", "code"]]

__END__

James Edward Gray II

Pit Capitain

1/18/2007 8:55:00 PM

0

David Chelimsky schrieb:
> I find that I do a lot of this:
>
> def initialize(thing, other)
> @thing = thing
> @other = other
> end
>
> One thing I'd love to see in a future version of ruby is this;
>
> def initialize(@thing, @other)
> end

Not that I would do it, but:

class C
define_method :initialize do |@x, @y|
end
end

c = C.new 1, 2
p c # => #<C:0x2aeabd0 @y=2, @x=1>

I think Matz is planning to deprecate this feature.

Regards,
Pit

Ara.T.Howard

1/18/2007 9:02:00 PM

0

Daniel Berger

1/18/2007 9:33:00 PM

0


David Chelimsky wrote:
> I see where to put bugs and patches, but this is a feature request. Is
> this the right place to submit these?
>
> In any case, here's a feature request:
>
> I find that I do a lot of this:
>
> def initialize(thing, other)
> @thing = thing
> @other = other
> end
>
> One thing I'd love to see in a future version of ruby is this;
>
> def initialize(@thing, @other)
> end
>
> .. and have that automagically initialize @thing and @other with the
> submitted values.

I could have sworn Paul Brannan did this as part of RubyTreasures, but
I don't see any such thing mentioned in the docs. I know it's been
done somewhere as a language hack.

Personally, I think it ought to be the default behavior, since it's
what you want about 80% of the time in practice I think. At worst,
you've got a couple of useless instance variables that people would
have to go to pains to get at via instance_variable_get. Heck, why not
take this a step further and create automatic getters and setters? You
can always undef or redefine them.

Regards,

Dan

David Chelimsky

1/18/2007 9:33:00 PM

0

On 1/18/07, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> On Fri, 19 Jan 2007, Pit Capitain wrote:
>
> > David Chelimsky schrieb:
> >> I find that I do a lot of this:
> >>
> >> def initialize(thing, other)
> >> @thing = thing
> >> @other = other
> >> end
> >>
> >> One thing I'd love to see in a future version of ruby is this;
> >>
> >> def initialize(@thing, @other)
> >> end
> >
> > Not that I would do it, but:
> >
> > class C
> > define_method :initialize do |@x, @y|
> > end
> > end
> >
> > c = C.new 1, 2
> > p c # => #<C:0x2aeabd0 @y=2, @x=1>
> >
> > I think Matz is planning to deprecate this feature.
> >
> > Regards,
> > Pit
>
> harp:~ > cat a.rb
> require 'rubygems'
> require 'attributes'
>
> class C
> attributes %w( a b c )
>
> def initialize *argv
> self.class.attributes.zip(argv){|a,v| send a, v}
> end
> end
>
> p(C.new(0,1,2))
>
> 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 ;) 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

James Gray

1/18/2007 9:58:00 PM

0

On Jan 18, 2007, at 3:35 PM, Daniel Berger wrote:

> Heck, why not
> take this a step further and create automatic getters and setters? You
> can always undef or redefine them.

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.

James Edward Gray II

Gregory Brown

1/18/2007 10:06:00 PM

0

On 1/18/07, James Edward Gray II <james@grayproductions.net> 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.

Daniel Berger

1/18/2007 10:44:00 PM

0

James Edward Gray II wrote:
> On Jan 18, 2007, at 3:35 PM, Daniel Berger wrote:
>
> > Heck, why not
> > take this a step further and create automatic getters and setters? You
> > can always undef or redefine them.
>
> 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.

Hm, you're probably right.

I suppose it would require some fundamental changes to the language,
i.e. not allowing instance data to be set directly outside of the
constructor (forcing you to use the actual getter and setter methods
outside of the constructor). This is what Fortress does, and I think
it's what Perl 6 will do as well.

I'm not sure what the downside of that change would be, other than a
forced method lookup. I don't know enough about Ruby internals to know
if "@foo = 1" is cheaper than "foo = 1", but I'm guessing that it is.

Forgive me, for I have been tainted by the Fortress language recently.
:)

Regards,

Dan