Idea: def end returns the symbolized version of the newly-defined method, instead of nil

Ruby
1

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

2

What is gained from doing this? What problem does it solve?

3

On Aug 13, 2012, at 12:59 , Peter [email protected] wrote:

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

4

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

5

Forgot:

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. :slight_smile:

6

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.

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

7

On Aug 14, 2012, at 7:42 PM, Peter [email protected] wrote:

Forgot:

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. :slight_smile:

oh

8

On Aug 14, 2012, at 7:41 PM, Peter [email protected] 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.

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.

9

On Wed, Aug 15, 2012 at 4:41 AM, Peter [email protected] 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