This would allow useful syntax constructs such as this:
protected def protected_method
...
end
and
private def private_method
...
end
I hear from #ruby that this may have been proposed years ago. Also, the
symbolized version of the method_name is instantiated anyway already, so
the extra cost is nil. Thoughts? Why no traction?
-Peter Marreck
···
--
"I'd put my money on the sun and solar energy. What a source of power! I
hope we don't have to wait until oil and coal run out before we tackle
that."
-Thomas Edison, 1931
Not sure if you've ever worked on large classes in large Ruby/Rails
projects (unless you want to count "possible code smell" as an argument
against this, putting that aside for a moment) but if a "protected" or
"private" block is fairly large, it gets difficult to see what's going on
without doing "private :method_just_defined_on_previous_line" dozens of
times (which to me is a different kind of smell, but some consider it a
valid style).
Since a symbol is already created when a method is defined, and we are
dealing with a functional language (or one with functional aspects), I just
think it would be useful for a def to return something other than "nil",
and it would nicely dovetail with the fact that "protected" and "private"
can take symbol arguments. There are no extra costs involved.
Personally, I've never found protected/private to be useful.
Your anecdotal experience does not count as evidence towards utility.
Do note that your proposed "syntax" above is mostly achieved with 2 chars
added:
No, actually that only works for the case of 2 methods, one protected and
one private. If you have 10 protected methods and 10 private methods, the
situation quickly becomes more complicated.
-Peter
···
On Mon, Aug 13, 2012 at 9:17 PM, Ryan Davis <ryand-ruby@zenspider.com>wrote:
On Aug 13, 2012, at 12:59 , Peter <lumbergh@gmail.com> wrote:
> This would allow useful syntax constructs such as this:
>
> protected def protected_method
> ...
> end
>
> and
>
> private def private_method
> ...
> end
Personally, I've never found protected/private to be useful. Do note that
your proposed "syntax" above is mostly achieved with 2 chars added:
protected; def protected_method
...
end
and
private; def private_method
...
end
and so I really don't see the point. Esp if you've ever gotten used to
reading idiomatic java, then the newline looks fine:
protected
def protected_method
...
end
and
private
def private_method
...
end
--
"I'd put my money on the sun and solar energy. What a source of power! I
hope we don't have to wait until oil and coal run out before we tackle
that."
-Thomas Edison, 1931
Esp if you've ever gotten used to reading idiomatic java
I have never had to get used to Java on my way to Ruby and I consider that
a perk. AND an achievement.
···
On Tue, Aug 14, 2012 at 10:41 PM, Peter <lumbergh@gmail.com> wrote:
Not sure if you've ever worked on large classes in large Ruby/Rails
projects (unless you want to count "possible code smell" as an argument
against this, putting that aside for a moment) but if a "protected" or
"private" block is fairly large, it gets difficult to see what's going on
without doing "private :method_just_defined_on_previous_line" dozens of
times (which to me is a different kind of smell, but some consider it a
valid style).
Since a symbol is already created when a method is defined, and we are
dealing with a functional language (or one with functional aspects), I just
think it would be useful for a def to return something other than "nil",
and it would nicely dovetail with the fact that "protected" and "private"
can take symbol arguments. There are no extra costs involved.
> Personally, I've never found protected/private to be useful.
Your anecdotal experience does not count as evidence towards utility.
> Do note that your proposed "syntax" above is mostly achieved with 2
chars added:
No, actually that only works for the case of 2 methods, one protected and
one private. If you have 10 protected methods and 10 private methods, the
situation quickly becomes more complicated.
-Peter
On Mon, Aug 13, 2012 at 9:17 PM, Ryan Davis <ryand-ruby@zenspider.com>wrote:
On Aug 13, 2012, at 12:59 , Peter <lumbergh@gmail.com> wrote:
> This would allow useful syntax constructs such as this:
>
> protected def protected_method
> ...
> end
>
> and
>
> private def private_method
> ...
> end
Personally, I've never found protected/private to be useful. Do note that
your proposed "syntax" above is mostly achieved with 2 chars added:
protected; def protected_method
...
end
and
private; def private_method
...
end
and so I really don't see the point. Esp if you've ever gotten used to
reading idiomatic java, then the newline looks fine:
protected
def protected_method
...
end
and
private
def private_method
...
end
--
"I'd put my money on the sun and solar energy. What a source of power! I
hope we don't have to wait until oil and coal run out before we tackle
that."
-Thomas Edison, 1931
--
"I'd put my money on the sun and solar energy. What a source of power! I
hope we don't have to wait until oil and coal run out before we tackle
that."
-Thomas Edison, 1931
Seems like a nice idea to me. I have absolutely no idea what negative implications it might have. I have gotten into the habit of doing this (which I'm sure the Ruby community will be horrified by, but I quite like)
def foo
...
end; private :foo
Sam
···
On 08/15/2012 02:41 PM, Peter wrote:
Since a symbol is already created when a method is defined, and we are dealing with a functional language (or one with functional aspects), I just think it would be useful for a def to return something other than "nil", and it would nicely dovetail with the fact that "protected" and "private" can take symbol arguments. There are no extra costs involved.
Not sure if you've ever worked on large classes in large Ruby/Rails projects (unless you want to count "possible code smell" as an argument against this, putting that aside for a moment) but if a "protected" or "private" block is fairly large, it gets difficult to see what's going on without doing "private :method_just_defined_on_previous_line" dozens of times (which to me is a different kind of smell, but some consider it a valid style).
Since a symbol is already created when a method is defined, and we are dealing with a functional language (or one with functional aspects), I just think it would be useful for a def to return something other than "nil", and it would nicely dovetail with the fact that "protected" and "private" can take symbol arguments. There are no extra costs involved.
> Personally, I've never found protected/private to be useful.
Your anecdotal experience does not count as evidence towards utility.
I didn't offer it as evidence. I offered it as an opinion.
But since you want evidence of utility... There IS no utility to protected/private in ruby. All methods are callable. Always.
> Do note that your proposed "syntax" above is mostly achieved with 2 chars added:
No, actually that only works for the case of 2 methods, one protected and one private. If you have 10 protected methods and 10 private methods, the situation quickly becomes more complicated.
I hardly think that adding a semicolon N times is "complicated". Please. Stick to arguments that at least make sense.
Again. Replace the ";" with a newline and it becomes obvious how this proposal doesn't provide much value.
···
On Aug 14, 2012, at 7:41 PM, Peter <lumbergh@gmail.com> wrote:
Not sure if you've ever worked on large classes in large Ruby/Rails projects
(unless you want to count "possible code smell" as an argument against this,
putting that aside for a moment) but if a "protected" or "private" block is
fairly large, it gets difficult to see what's going on without doing
"private :method_just_defined_on_previous_line" dozens of times (which to me
is a different kind of smell, but some consider it a valid style).
We had this question about ordering large number of methods the other
day. My stance is that you should not have that many methods in the
first place, i.e. it's a code smell.
And I prefer grouping methods by visibility because that makes it much
easier to understand the public API of a class - which is important
for users of a class. Then you don't have the case of mixing public,
protected and private methods.
Since a symbol is already created when a method is defined, and we are
dealing with a functional language (or one with functional aspects), I just
think it would be useful for a def to return something other than "nil", and
it would nicely dovetail with the fact that "protected" and "private" can
take symbol arguments. There are no extra costs involved.
That seems like a fair analysis. Only that I am not sure about the
symbol being created. But even if that would be an additional task
the overhead would probably not be too big.
Do note that your proposed "syntax" above is mostly achieved with 2 chars
added:
No, actually that only works for the case of 2 methods, one protected and
one private. If you have 10 protected methods and 10 private methods, the
situation quickly becomes more complicated.
I think Ryan wanted to suggest to prefix *all* method definitions with
the visibility. In that case it would work with more than two
methods.
Kind regards
robert
···
On Wed, Aug 15, 2012 at 4:41 AM, Peter <lumbergh@gmail.com> wrote:
