Forum: Ruby auto assign arguments?

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.
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2007-01-19 16:30
(Received via mailing list)
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
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2007-01-19 16:30
(Received via mailing list)
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://rcrchive.net/

Gary Wright
93d566cc26b230c553c197c4cd8ac6e4?d=identicon&s=25 Pit Capitain (Guest)
on 2007-01-19 16:30
(Received via mailing list)
David Chelimsky schrieb:
> 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
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2007-01-19 16:31
(Received via mailing list)
On Fri, 19 Jan 2007, Pit Capitain wrote:

>> def initialize(@thing, @other)
>  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>


-a
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2007-09-25 22:30
(Received via mailing list)
From: "David Chelimsky" <dchelimsky@gmail.com>
> #results in an instance variable @a with a value of 5
As I recall, this was proposed on this list several years ago.

I think it generated a bit of discussion, with possibly even
some comments by Matz.

Sorry, I don't have a link to the thread in the archives,
though...


Regards,

Bill
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2007-09-25 22:31
(Received via mailing list)
Hi,

In message "Re: auto assign arguments?"
    on Sat, 20 Jan 2007 01:58:06 +0900, "David Chelimsky"
<dchelimsky@gmail.com> writes:

|Would you mind providing a brief explanation of your objection? There
|is no Reason for rejection with the old RCR
|(http://oldrcrs.rubypal.com/rejected.html#rcr3) and it would be
|helpful to me (and I'm sure others) to understand why you think this
|is a bad idea.

I thought (and I still think) it is a good idea to separate method
argument and assignment in general.  It's convention supported by most
languages, and mixing parameters and assignments gives me impression
of toy-language.

Besides that, I think formal arguments of a method (including their
names) can be seen as part of class API.  Allowing instance variables
as formal arguments seems like disclosing the internal issues.

Finally, I admit that the code like this

  def initialize(@length)
  end

is longer than

  def initialize(length)
    @length = length
  end

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

              matz.
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2007-09-25 22:32
(Received via mailing list)
On 1/20/07, David Chelimsky <dchelimsky@gmail.com> wrote:
> > > <snip>
> > just would be a willful disclosure a little bit like
> >        attr_writer :length
> >
>
> Thinking about this some more - I wasn't proposing this become part of
> the API. Nor would I want to see this anywhere besides the
> initializer. The proposal is that for initializers (only) you could


Ah I see here we are really diverging. Are you aware that you propose
different formal parameter symantics based on
the method name?
OTOH #initialize is a *special* method of course. But I am against it,
would
make the language more complicated.

define (not reference pre-existing) instance variables:
>
> def initialize(@length)
> end
>
> If this were allowed, there would be no need to expose the @ in RDoc.
> RDoc could be tweaked to hide that, so you'd still just see:


Again I fail to agree :(.
If you exposed an instance variable like that would it not be desired
for
RDoc to document this?

new(length)
>
> Note that RDoc is already hiding initialize (as an instance method)
> and showing you new (as a class method), so this would just be an
> addition to that transformation.
>
> So the proposed sugar would only be exposed to the intialize method
> and anybody (human or machine) reading the class definition.
>
> David
> <snip>


Robert
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2007-09-25 22:33
(Received via mailing list)
On Jan 18, 2007, at 2:13 PM, David Chelimsky wrote:

> 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
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2007-09-25 22:33
(Received via mailing list)
On 1/20/07, Robert Dober <robert.dober@gmail.com> wrote:
> > Besides that, I think formal arguments of a method (including their
>
Thinking about this some more - I wasn't proposing this become part of
the API. Nor would I want to see this anywhere besides the
initializer. The proposal is that for initializers (only) you could
define (not reference pre-existing) instance variables:

def initialize(@length)
end

If this were allowed, there would be no need to expose the @ in RDoc.
RDoc could be tweaked to hide that, so you'd still just see:

new(length)

Note that RDoc is already hiding initialize (as an instance method)
and showing you new (as a class method), so this would just be an
addition to that transformation.

So the proposed sugar would only be exposed to the intialize method
and anybody (human or machine) reading the class definition.

David
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-09-25 22:33
(Received via mailing list)
On 1/18/07, Gregory Brown <gregory.t.brown@gmail.com> wrote:
> On 1/18/07, David Chelimsky <dchelimsky@gmail.com> 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
> this syntactic sugar.

<whoops>

This syntactic sugar would confuse me.
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2007-09-25 22:35
(Received via mailing list)
On 1/19/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
>
> |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,

Thank you for weighing in on this discussion (and, this being the
first time I've addressed you directly, thanks for this beautiful
language).

Would you mind providing a brief explanation of your objection? There
is no Reason for rejection with the old RCR
(http://oldrcrs.rubypal.com/rejected.html#rcr3) and it would be
helpful to me (and I'm sure others) to understand why you think this
is a bad idea.

Cheers,
David
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-09-25 22:36
(Received via mailing list)
On 1/18/07, David Chelimsky <dchelimsky@gmail.com> 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
this syntactic sugar.
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2007-09-25 22:36
(Received via mailing list)
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
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2007-09-25 22:36
(Received via mailing list)
On 1/20/07, Robert Dober <robert.dober@gmail.com> wrote:
>
>
> <cut>




Sorry  for replying to myself, but this stroke me too funny to resist:
>



Ah I see here we are really diverging. Are you aware that you propose
> different formal parameter symantics based on
> the method name?
>

Of course symantics was a stupid typo but actually it is the "correct"
word,
syntax and semantics would be different, amazing.

<cut>
>
Robert
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2007-09-25 22:36
(Received via mailing list)
On 1/20/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> in Ruby, but too much implicit behavior makes our programs into
> puzzles.  It's matter of balance.

Hear, hear!!!!

I respectfully withdraw the suggestion.


Cheers,
David
Aee77dba395ece0a04c688b05b07cd63?d=identicon&s=25 Daniel Berger (Guest)
on 2007-09-25 22:36
(Received via mailing list)
dblack@wobblini.net wrote:
> > created and initialized with the submitted value. So:
> http://oldrcrs.rubypal.com/rejected.html#rcr3
Hm, no reason given, but one of the things I don't like about it is the
change in syntax it required.  With the advent of keyword parameters
(right?), and the ability to get the parameter names from within a
method, this should be trivial to implement on our own in 1.9 if Matz
doesn't want it as the default behavior.

Dan
Aee77dba395ece0a04c688b05b07cd63?d=identicon&s=25 Daniel Berger (Guest)
on 2007-09-25 22:38
(Received via mailing list)
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
4e8d94859927eab3b50486d21249c068?d=identicon&s=25 Paulo Köch (Guest)
on 2007-09-25 22:38
(Received via mailing list)
Ok, this isn't quite an answer, but why not using editor macros?

Just a thought, don't flame me.

Paulo Jorge Duarte
Köchpaulo.koch@gmail.com
Aee77dba395ece0a04c688b05b07cd63?d=identicon&s=25 Daniel Berger (Guest)
on 2007-09-25 22:41
(Received via mailing list)
David Chelimsky wrote:
> 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
E0526a6bf302e77598ef142d91bdd31c?d=identicon&s=25 Daniel DeLorme (Guest)
on 2007-09-25 22:42
(Received via mailing list)
Yukihiro Matsumoto wrote:
> I thought (and I still think) it is a good idea to separate method
> argument and assignment in general.  It's convention supported by most
> languages, and mixing parameters and assignments gives me impression
> of toy-language.

That's interesting. Would you mind sharing your insight on why these
should be
separated? To me they seem similar enough to be "merged". I think the
only
reason to separate them is because, at the machine-language level,
function
arguments are PUSHed onto the stack while assignments are MOVed to
memory. So
historically they come from different mechanisms. But if we agree that
computer
languages should be designed for humans, not computers, it seems more
natural to
view parameters as a specialized case of assignment.

> Besides that, I think formal arguments of a method (including their
> names) can be seen as part of class API.  Allowing instance variables
> as formal arguments seems like disclosing the internal issues.

I can see the number of arguments (and in other languages, their type)
as part
of the class API, but not their names since those variables' names are
local to
the method. True, rdoc exposes those internals in the documentation, but
then it
also exposes the instance variables & methods used for default values.
For
consistency I think instance variables should be allowed as parameters
since
they are allowed as default values. But I acknowledge that consistency
may not
be the most important factor to consider here.

I dunno, forbidding instance variables may be the more "correct"
approach but I
think allowing them would be more useful. One of the reasons I like ruby
is
because it favors usefulness over strict "correctness" (e.g. you can
still get
to private methods if you really need it)

just my 2円

Daniel
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2007-09-25 22:42
(Received via mailing list)
From: "Bill Kelly" <billk@cts.com>
>>
>> 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.  <grin>

http://groups.google.com/group/comp.lang.ruby/brow...



HTH,

Bill
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2007-09-25 22:43
(Received via mailing list)
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
D032dc2ce8e6e785161fb4e3ebb64ba3?d=identicon&s=25 Kalman Noel (Guest)
on 2007-09-25 22:43
(Received via mailing list)
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
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2007-09-25 22:44
(Received via mailing list)
On 1/18/07, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> 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 ;) 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
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2007-09-25 22:45
(Received via mailing list)
On 1/19/07, Yukihiro Matsumoto <matz@ruby-lang.org> 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 ;)
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
:(
Sorry folks
R.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-09-25 22:46
(Received via mailing list)
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.
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2007-09-25 22:47
(Received via mailing list)
On 1/19/07, David Chelimsky <dchelimsky@gmail.com> 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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2007-09-25 22:47
(Received via mailing list)
On 18.01.2007 21:25, Kalman Noel 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. :-)

  robert
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2007-09-25 22:48
(Received via mailing list)
On Jan 18, 2007, at 5:06 PM, Gregory Brown 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 Wright

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
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2007-09-25 22:48
(Received via mailing list)
On 1/19/07, Yukihiro Matsumoto <matz@ruby-lang.org> 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 ;)

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 ;)

                                                        matz.
>
>
Cheers
Robert
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2007-09-25 22:49
(Received via mailing list)
Hi,

In message "Re: auto assign arguments?"
    on Fri, 19 Jan 2007 22:15:33 +0900, "Robert Dober"
<robert.dober@gmail.com> 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.
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2007-09-25 22:49
(Received via mailing list)
Hi,

In message "Re: auto assign arguments?"
    on Sat, 20 Jan 2007 15:26:59 +0900, Daniel DeLorme
<dan-ml@dan42.com> 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.
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2007-09-25 22:49
(Received via mailing list)
On 1/19/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
>
>
> former.
Very helpful. Thanks for the clarification.

Cheers,
David
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-09-25 22:51
(Received via mailing list)
On 1/18/07, Daniel DeLorme <dan-ml@dan42.com> 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)
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2007-09-25 22:52
(Received via mailing list)
On 1/19/07, dblack@wobblini.net <dblack@wobblini.net> 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
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2007-09-25 22:52
(Received via mailing list)
Hi --

On Fri, 19 Jan 2007, David Chelimsky 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
E0526a6bf302e77598ef142d91bdd31c?d=identicon&s=25 Daniel DeLorme (Guest)
on 2007-09-25 22:53
(Received via mailing list)
Gregory Brown wrote:
> On 1/18/07, David Chelimsky <dchelimsky@gmail.com> 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 topic is locked and can not be replied to.