Feature #19644: Module::current to complement Module::nesting

• Status: Rejected
• Assignee: -
• Target version: -

[bughit (bug hit)]

Module::current == Module::nesting[0] but without needlessly walking the entire nesting hierarchy.

Could be useful for debugging/logging.

It could also be a Kernel global (like __method__) or a keyword (like __FILE__)

[Eregon (Benoit Daloze)]

Is self not enough? This needs a concrete use case.

[bughit (bug hit)]

Eregon (Benoit Daloze) wrote in #note-1:

Is self not enough? This needs a concrete use case.

Module::nesting[0] is the current lexically open module/class, its not self

[Eregon (Benoit Daloze)]

• Has duplicate Feature #19682: ability to get a reference to the "default definee" added

[Eregon (Benoit Daloze)]

In a module body it's the same.
So why do you need it? Isn't it trivially accessible via other ways?

[Eregon (Benoit Daloze)]

• Status changed from Open to Rejected

Could be useful for debugging/logging.

Those are not performance critical, so Module::nesting[0] is enough.

You also don't want to provide a concrete example where it's a clear gain, OK, let's close then until there is a clear use case for it where Module::nesting[0] is not enough.

[Eregon (Benoit Daloze)]

• Has duplicate deleted (Feature #19682: ability to get a reference to the "default definee" )

[bughit (bug hit)]

• Description updated (diff)

Eregon (Benoit Daloze) wrote in #note-5:

Could be useful for debugging/logging.

Those are not performance critical, so Module::nesting[0] is enough.

They could be if invoked frequently enough.

You also don't want to provide a concrete example where it's a clear gain, OK, let's close then until there is a clear use case for it where Module::nesting[0] is not enough.

Module::nesting[0] has to walk and build the entire nesting chain. This is undesirable if you just want the current module.

If you don't know the difference between self and Module::nesting[0], you're not qualified to reject this. Reopen it.

class Class1
  def foo
    puts "#{Module.nesting[0]}##{__method__}" # Class1#foo
    puts "#{self.class}##{__method__}"        # Class2#foo
  end
end

class Class2 < Class1
  def foo
    super
  end
end

Class2.new.foo

[bughit (bug hit)]

ioquatix (Samuel Williams) wrote:

In some cases, where things like Module.nesting[n] is too slow, having an argument like Module.nesting(n) or such which gets the first n

Module.nesting(n) does address the perf aspect, but it makes rather it too verbose and obfuscated/ugly to get the current: Module.nesting(1)[0]. It ought to be more compact, perhaps just __module__ like __method__

[ioquatix (Samuel Williams)]

I think __module__ (or __namespace__ etc) could be acceptable, but in order to discuss it further we just need to understand the use case. If you can use the feature request template, it will help us triage and discuss the issue.

Are you saying in all cases it would be the same as Module.nesting[0]?

[nobu (Nobuyoshi Nakada)]

bughit (bug hit) wrote in #note-8:

Module.nesting(n) does address the perf aspect, but it makes rather it too verbose and obfuscated/ugly to get the current: Module.nesting(1)[0].

I thought it would be Module.nesting(0), or Module.nesting(0..)[0].

[ioquatix (Samuel Williams)]

Ah yep, that seems reasonable to me.

[bughit (bug hit)]

nobu (Nobuyoshi Nakada) wrote in #note-10:

bughit (bug hit) wrote in #note-8:

Module.nesting(n) does address the perf aspect, but it makes rather it too verbose and obfuscated/ugly to get the current: Module.nesting(1)[0].

I thought it would be Module.nesting(0), or Module.nesting(0..)[0].

Module::nesting(index_or_range) returning a module for an index, looks like an easy enhancement of the existing method. It should probably be done regardless, it's just better API design. Still, a single label identifier without arguments (like __mod(ule)__) looks better: "#{__module__}##{__method__}"

I already mentioned one use-case, logging/tracing. Basically any kind of generic code that you might place in multiple methods in multiple classes, that needs to refer to the current class/module.

[Eregon (Benoit Daloze)]

bughit (bug hit) wrote in #note-12:

Still, a single label identifier without arguments (like __mod(ule)__) looks better: "#{__module__}##{__method__}"

Finally a concrete example (although partial): logging with "#{__module__}##{__method__}".
We asked many times, I am not sure why you waited so long to show this one.
One can maybe guess what you want, but that is not productive and will not help the ticket, it will only waste time.
At a developer meeting, or earlier, if there is no concrete use case, either the proposal will be skipped or closed (maybe as Feedback to reflect the lack of a convincing and concrete example, maybe Rejected for not following the template).
It should have been part of the issue description as the template says.
The template could be more explicit that an example with Ruby code is the most important, however this has already been mentioned to you in here (and many other times) and is also what I meant by This needs a concrete use case. I'll improve the template in that direction.
And of course ideally the template should be shown when opening a new feature, there have been discussions to do that.

Now going to this example, there are two problems:

• This means every time one wants to do tracing/logging like that, they cannot just use LOGGER.info "message", they would need to use LOGGER.info "#{__module__}##{__method__} message". That seems very inconvenient. Maybe you want to access the caller's module? That is a different proposal then.
• This is confusing and incorrect if in a method inside class_exec/module_exec/instance_exec:

module Foo
  def self.setup(klass)
    klass.class_exec do
      def bar
        LOGGER.info "#{__module__}##{__method__} message" # incorrect, will show `Foo#bar`, but no such method was ever defined in this program
      end
    end
  end
end

Foo.setup(String)

So probably the default definee would be better for that. Of course it does not address the first point.
Maybe you can realize now why I think this is closely related or a duplicate with #19682:

• They both didn't have a concrete example, were filed closely in time, and are talking about related concepts, so the use case might mix both.
• If the use case is logging, it seems you might want the default definee and not Module.nesting[0].

I also think it's of little practical value to have the module (and method) there. For the rare cases it'd be useful, one could just write the module name by hand to help tracing/debugging, or likely more useful words to identify that place (e.g. when printing in multiple places in a method). If you want to trace every method call that is also possible with TracePoint.
The file and line can already be shown, and they can be queried for the caller, so LOGGER.info "message" can show INFO: foo.rb:5 message already today. That seems plenty and is more precise.

Both of these issues are closed now, you can see I am not the only one which has a problem with such vague feature requests and the way you communicate.

---

Now I want to reply to some of your disrespectful comments, because it may help you find a better way to communicate with others.
So, apparently you are mixing both concepts of Module.nesting and default definee in this issue with the logging use case.
But yet I am not going to harass you about it, I will say it here only once, without any pejorative adjective.

In contrast, you keep claiming I don't know when it's clear I know very well.
The fact you repeat it many times does not make it more true, nobody will be fooled by that, it is just more obvious you harass people and do not know how to communicate properly.
Also you must realize that attacking everyone on this bug tracker like https://bugs.ruby-lang.org/issues/19682#note-26 is not productive and will not help your proposal, it will only help you get banned.
If you think everyone is wrong, most likely it is not the case, probably you are misreading or misinterpreting what they said or you are wrong.

In the future, and for the last time, do communicate as an adult, never harass or insult others, or leave this bug tracker/mailing list.
Never use Ad hominem, discuss and argue the substance, not the person.
That also implies no pejorative adjectives in what you write.
It might be a good idea to ask someone to review your replies before posting them to make sure they are appropriate.

[Eregon (Benoit Daloze)]

• Related to Feature #19682: ability to get a reference to the "default definee" added