Feature #8839

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

Added by Charles Nutter over 1 year ago. Updated 10 months ago.

[ruby-core:56890]
Status:Assigned
Priority:Normal
Assignee:Yukihiro Matsumoto

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 over 1 year 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 over 1 year ago

+1

#3 Updated by Charles Nutter over 1 year 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 over 1 year ago

+1

#5 Updated by Nobuyoshi Nakada over 1 year ago

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

#6 Updated by Charlie Somerville over 1 year 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 over 1 year 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 over 1 year ago

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

#9 Updated by Rodrigo Rosenfeld Rosas over 1 year ago

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

#10 Updated by Charles Nutter over 1 year 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 over 1 year 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 over 1 year 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
  internal_ary = []
  # ... 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
  internal_ary = []
  # ...
  internal_ary.each do |elem|
    # ...
  end
  nil
end

Yusuke Endoh mame@tsg.ne.jp

#13 Updated by Charles Nutter over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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:

assert_equal '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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year ago

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

#21 Updated by Charles Nutter over 1 year ago

jballanc (Joshua Ballanco) wrote:

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

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

  enumerable class Foo ...

#22 Updated by Alexey Muranov 10 months ago

+1. I do not want to share my silly code where i would use it, but currently it may look something like that:

def MyClass
  # ...
  self
end.define_more_methods(x, y, z).freeze

Also available in: Atom PDF