Feature #8839

Class and module should return the class or module that was opened

Added by Charles Nutter 8 months ago. Updated 5 months ago.

[ruby-core:56890]
Status:Assigned
Priority:Normal
Assignee:Yukihiro Matsumoto
Category:-
Target version:next minor

Description

With the change for https://bugs.ruby-lang.org/issues/3753, "def" forms now return the symbolic name of the method defined. Because class and module bodies just return the last expression in their bodies, this means they will now usually end up returning a symbol for the last method defined. This does not seem useful or correct.

I think class and module should return a reference to the class or module just opened. This would make the return value useful and consistent.

History

#1 Updated by Marc-Andre Lafortune 8 months ago

When thinking of potential incompatibilities, the only case I could think of where I'd ever used the result of class or module was:

class << foo
  self
end

Ironically, the proposed change would not introduce an incompatibility in this case :-)

#2 Updated by Boris Stitnicky 8 months ago

+1

#3 Updated by Charles Nutter 7 months ago

So...if there's no objections, can we get this into 2.1? I think with the new def return value change it really needs to happen.

#4 Updated by Thomas Enebo 7 months ago

+1

#5 Updated by Nobuyoshi Nakada 7 months ago

No, class and def are evaluated in different timings.
This proposal makes no sense.

#6 Updated by Charlie Somerville 7 months ago

nobu: I don't understand what you mean by "evaluated in different timings". Could you please explain?

I think this proposal is a good idea. For example, this makes no sense:

class A
  def foo
  end
end # => :foo

But this makes more sense:

class A
  def foo
  end
end # => A

#7 Updated by Yusuke Endoh 7 months ago

  • Status changed from Open to Assigned
  • Assignee set to Yukihiro Matsumoto
  • Target version set to next minor

How useful is this proposal?
I think we should not change anything without consideration of use case.

Yusuke Endoh mame@tsg.ne.jp

#8 Updated by Rodrigo Rosenfeld Rosas 7 months ago

I've been wondering the same thing since I saw this ticket being created...

#9 Updated by Rodrigo Rosenfeld Rosas 7 months ago

Actually, I don't understand even why returning a symbol from method definition is useful...

#10 Updated by Charles Nutter 7 months ago

mame (Yusuke Endoh) wrote:

How useful is this proposal?
I think we should not change anything without consideration of use case.

One use:

my_class = class Foo
...
end

We can get the reference to a class being created immediately without adding "self" at the end. It also brings some equivalence with my_class = Class.new.

Another:

class Foo
def self.init
@foo = Foo.new
end
end.init

The use cases I can think of are all fairly subtle, but I think they're valid.

Ultimately, the biggest reason I think this should happen is because class Foo; def bar; end; end returning :bar in 2.1 makes very little sense.

#11 Updated by Rodrigo Rosenfeld Rosas 7 months ago

I see now. I really tried a few times to get something like your second example to work:

class MyProcessor
...
end.new(params).process

I'd usually use such pattern in small scripts since methods are not hoisting like functions declarations in JavaScript and I prefer to write code top-down, so I enclose them in a class.

#12 Updated by Yusuke Endoh 7 months ago

headius (Charles Nutter) wrote:

One use:

my_class = class Foo
...
end

We can get the reference to a class being created immediately without adding "self" at the end.

I fail to see why it needs to be a local variable.
Why don't you use Foo instead of my_class?

Another:

class Foo
def self.init
@foo = Foo.new
end
end.init

The use cases I can think of are all fairly subtle, but I think they're valid.

It is very arguable if the new idiom should be encouraged.
Personally, I don't like to see such a code. Rather, I prefer:

class Foo
def self.init
@foo = Foo.new
end
self.init
end

or even:

class Foo
@@foo = Foo.new
end

Ultimately, the biggest reason I think this should happen is because class Foo; def bar; end; end returning :bar in 2.1 makes very little sense.

IMHO, most of casual users do not care too much for a return value.
For example, we often see the following type of code:

def foo
internalary = []
# ... building internal
ary ...
internal_ary.each do |elem|
# ... using elem ...
end
end

Obviously, the author of this method has no intent to return internal_ary.
But, few people writes a code that returns nil explicitly to hide the value.

def foo
internalary = []
# ...
internal
ary.each do |elem|
# ...
end
nil
end

Yusuke Endoh mame@tsg.ne.jp

#13 Updated by Charles Nutter 7 months ago

mame (Yusuke Endoh) wrote:

headius (Charles Nutter) wrote:

One use:

my_class = class Foo
...
end

We can get the reference to a class being created immediately without adding "self" at the end.

I fail to see why it needs to be a local variable.
Why don't you use Foo instead of my_class?

How about this:

meta = class << self; end

It is very arguable if the new idiom should be encouraged.
Personally, I don't like to see such a code. Rather, I prefer:

class Foo
def self.init
@foo = Foo.new
end
self.init
end

or even:

class Foo
@@foo = Foo.new
end

I respect your opinion, but I fail to see why your way is better than mine.

Ultimately, the biggest reason I think this should happen is because class Foo; def bar; end; end returning :bar in 2.1 makes very little sense.

IMHO, most of casual users do not care too much for a return value.

Users not caring about return value is not a good reason to return a nonsensical value. Returning the last method name defined in a class body makes no sense. Returning the class that was just defined may not make sense to you, but it makes sense to me and several others who have commented here.

#14 Updated by Robert Gleeson 7 months ago

I agree that returning the class or module makes sense (to me).
I'd also like to see "def foo" return a (Unbound)Method instead of a Symbol.
it seems like that'd also make more sense (not to derail this conversation). A (Unbound)Method is much more useful.
I saw headius mention you can say:
class Foo
instance_method def foo
end # => UnboundMethod.
end
...but seems like a nice default.

+1 to the proposal.

#15 Updated by Yusuke Endoh 7 months ago

headius (Charles Nutter) wrote:

mame (Yusuke Endoh) wrote:

headius (Charles Nutter) wrote:

One use:

my_class = class Foo
...
end

We can get the reference to a class being created immediately without adding "self" at the end.

I fail to see why it needs to be a local variable.
Why don't you use Foo instead of my_class?

How about this:

meta = class << self; end

Use:

meta = self.singleton_class

It is very arguable if the new idiom should be encouraged.
Personally, I don't like to see such a code. Rather, I prefer:

class Foo
def self.init
@foo = Foo.new
end
self.init
end

or even:

class Foo
@@foo = Foo.new
end

I respect your opinion, but I fail to see why your way is better than mine.

Your way is too easy to overlook ".init" because a method call is not usually expected there.

Ultimately, the biggest reason I think this should happen is because class Foo; def bar; end; end returning :bar in 2.1 makes very little sense.

IMHO, most of casual users do not care too much for a return value.

Users not caring about return value is not a good reason to return a nonsensical value.

"It makes no sense" is not a good reason to change anything.
Rather, it is consistent and compatible to just return the last value.
We need better reason to break compatibility, I think.

This is my personal opinion, of course.

Yusuke Endoh mame@tsg.ne.jp

#16 Updated by Shugo Maeda 7 months ago

I did a quick hack to try this proposal and found that some test failed with it:

https://gist.github.com/shugo/6739085

For example, bootstraptest/test_block.rb uses the last value of a class definition as follows:

assertequal 'ok', %q{
STDERR.reopen(STDOUT)
class C
define
method(:foo) do |&block|
block.call if block
end
result = "ng"
new.foo() {result = "ok"}
result
end
}

If class definitions are changed to return the defined class, there'll be no way to get values created in class definitions except using global variables or constants, etc.
I'm not sure whether there's any use case of the current behavior other than testing purposes, but please consider there might be some users of the current behavior.

#17 Updated by Charles Nutter 7 months ago

shugo (Shugo Maeda) wrote:

I did a quick hack to try this proposal and found that some test failed with it:

https://gist.github.com/shugo/6739085

For example, bootstraptest/test_block.rb uses the last value of a class definition as follows:

The case given is rather contrived; I have never seen code in the wild use last expression return from a class.

If class definitions are changed to return the defined class, there'll be no way to get values created in class definitions except using global variables or constants, etc.

This is a fair point, I suppose, but I still see more reasons to make the return value consistent than leave it as is and have classes suddenly returning a symbol for the last defined method. Most folks probably don't even know about the return value since if you're just doing "def" as last expression it has always been nil.

#18 Updated by Avdi Grimm 7 months ago

On Sat, Sep 28, 2013 at 2:39 AM, shugo (Shugo Maeda)
redmine@ruby-lang.orgwrote:

For example, bootstraptest/test_block.rb uses the last value of a class
definition as follows:

The only time I've ever used the return value of a class definition it's
been to get the class itself, by making self the last statement in the
class definition.

That said, if you really wanted to preserve the ability to return something
other from a class definition, could you make break <SOME_VALUE> override
the return, as it does in blocks?

--
Avdi Grimm
http://avdi.org

I only check email twice a day. to reach me sooner, go to
http://awayfind.com/avdi

#19 Updated by Charles Nutter 7 months ago

avdi (Avdi Grimm) wrote:

That said, if you really wanted to preserve the ability to return something
other from a class definition, could you make break <SOME_VALUE> override
the return, as it does in blocks?

That wouldn't be backward-compatible with anyone expecting last expression, but it's an excellent idea to address Shugo's concern.

#20 Updated by Joshua Ballanco 5 months ago

=begin
Just to throw my 2¢ in...

I think the main benefit to returning a symbol from (({def})) is that it enables the use of method decorators. Similarly, I would be in favor of returning the class defined from (({class})) so that we could also build class decorators. A trivial example:

def enumerable(klass)
  klass.send(:include, Enumerable)
  klass
end

enumerable
class Foo
  #...
end

=end

#21 Updated by Charles Nutter 5 months ago

jballanc (Joshua Ballanco) wrote:

=begin
Just to throw my 2¢ in...

I think the main benefit to returning a symbol from (({def})) is that it enables the use of method decorators. Similarly, I would be in favor of returning the class defined from (({class})) so that we could also build class decorators. A trivial example:

def enumerable(klass)
  klass.send(:include, Enumerable)
  klass
end

enumerable
class Foo
  #...
end

=end

Clever! Though I don't think that would parse the way you want. This would work though, obviously:

enumerable class Foo ...

Also available in: Atom PDF