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
···
On 1/19/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
Hi --
On Fri, 19 Jan 2007, David Chelimsky 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:
>
> 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
>
> instance = MyClass.new(5)
> #results in an instance variable @a with a value of 5
> 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
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.
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).
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)
···
On 1/18/07, Daniel DeLorme <dan-ml@dan42.com> wrote:
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
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.
···
On 1/19/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
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.
--
"The best way to predict the future is to invent it."
- Alan Kay
>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,
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
···
On 1/19/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
In message "Re: auto assign arguments?" > on Fri, 19 Jan 2007 22:15:33 +0900, "Robert Dober" <robert.dober@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.
···
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.
Very helpful. Thanks for the clarification.
Cheers,
David
···
On 1/19/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
In message "Re: auto assign arguments?" > on Sat, 20 Jan 2007 01:58:06 +0900, "David Chelimsky" <dchelimsky@gmail.com> writes:
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)
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.
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
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.
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
···
On 1/19/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
In message "Re: auto assign arguments?" > on Sat, 20 Jan 2007 01:58:06 +0900, "David Chelimsky" < > dchelimsky@gmail.com> writes:
--
"The best way to predict the future is to invent it."
- Alan Kay
>
> Hi,
>
> <snip>
>
> 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.
Yes exactly but by explicit declaration, so
def set_length(@length)
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
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
···
On 1/20/07, Robert Dober <robert.dober@gmail.com> wrote:
On 1/19/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> In message "Re: auto assign arguments?" > > on Sat, 20 Jan 2007 01:58:06 +0900, "David Chelimsky" < > > dchelimsky@gmail.com> writes:
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
>
> 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.
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
--
"The best way to predict the future is to invent it."
- Alan Kay
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.
> >
> > Hi,
> >
> > <snip>
> >
> > 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.
>
> Yes exactly but by explicit declaration, so
>
> def set_length(@length)
>
> 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.
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
···
On 1/20/07, David Chelimsky <dchelimsky@gmail.com> wrote:
On 1/20/07, Robert Dober <robert.dober@gmail.com> wrote:
> On 1/19/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> > In message "Re: auto assign arguments?" > > > on Sat, 20 Jan 2007 01:58:06 +0900, "David Chelimsky" < > > > dchelimsky@gmail.com> writes:
--
"The best way to predict the future is to invent it."
- Alan Kay
>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.
Hear, hear!!!!
I respectfully withdraw the suggestion.
Cheers,
David
···
On 1/20/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
In message "Re: auto assign arguments?" > on Sat, 20 Jan 2007 15:26:59 +0900, Daniel DeLorme <dan-ml@dan42.com> writes:
