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

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

[bughit (bug hit)]

https://blog.yugui.jp/entry/846

"default definee" is a pretty important context so why not make it easy to identify?

Could be a Module class method or a global method (Kernel) or a keyword.

[Eregon (Benoit Daloze)]

• Is duplicate of Feature #19644: Module::current to complement Module::nesting added

[Eregon (Benoit Daloze)]

Seems a duplicate of #19644.
Again, why do you need it?
I think there is no chance to add something without a concrete use case/example, as I said in https://bugs.ruby-lang.org/issues/19644#note-1

[bughit (bug hit)]

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

Seems a duplicate of #19644.

Let's see. You thought Module::nesting[0] was the same as self. And now you think Module::nesting[0] is the same as "default definee". Wrong on both counts. Looks like you need these context references so you can figure out how ruby works. And I doubt you're the only one. Thanks for helping to make my case.

[Eregon (Benoit Daloze)]

Looks like you need these context references so you can figure out how ruby works.

@bughit (bug hit) This is a bit insulting, I know how Ruby work, I implemented all these concepts in TruffleRuby.
The point is these things are things Ruby needs to track internally, but the user probably has no need for.

[Eregon (Benoit Daloze)]

• Status changed from Open to Rejected

[Eregon (Benoit Daloze)]

• Is duplicate of deleted (Feature #19644: Module::current to complement Module::nesting)

[Eregon (Benoit Daloze)]

• Status changed from Rejected to Open

I didn't mean to close this one, only #19644, seems it's automatic somehow if linked as duplicate?

[bughit (bug hit)]

@bughit (bug hit) This is a bit insulting, I know how Ruby work, I implemented all these concepts in TruffleRuby.
The point is these things are things Ruby needs to track internally, but the user probably has no need for.

Not clear to me how you can implement these concepts and still be confused about the differences among self, Module::nesting[0] and "default definee". Are you sure you did it correctly? I've never used TruffleRuby but now I'm afraid to.

Let's take your latest pearl ("are things Ruby needs to track internally, but the user probably has no need for"), it evinces more confusion.

When a user uses def in various metaprogramming contexts, where that method ends up, depends on the current "default definee". And what it is, is not necessarily always obvious. The various rules for how the "default definee" shifts, both lexically and dynamically are in the blog linked in the OP. I wouldn't call them intuitable, you need to understand and remember them. So with that, why don't you try to answer again, does it matter to the user what class their method definitions are applied to? Or does it matter only to Ruby?

[Eregon (Benoit Daloze)]

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

Not clear to me how you can implement these concepts and still be confused about the differences among self, Module::nesting[0] and "default definee".

I am not confused, you misunderstood my reply in https://bugs.ruby-lang.org/issues/19644#note-1.
I was trying to help you by asking what you want to use this for concretely.
When you see such a contradiction, I suggest you think harder.

Module.nesting[0] is the same as self in a module body and in a singleton method. In a regular method it's just the self outside the def.
This is a trivial value, there is no point to add a new method for it. It's also visually trivial to identify the module and class keywords.
And Module.nesting is mostly relevant for constant lookup, and if you care about constant lookup, it's meaningless to only look at Module.nesting[0] but not other elements.

I ask you to not be needlessly rude and have some respect for committers.

Also it would be great if you can think by yourself how to better present your tickets so they have a chance to be accepted and not be so vague and IMO feel like spam.
"Could be useful for" is not a good enough motivation to open a ticket.

[Eregon (Benoit Daloze)]

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

Looks like you need these context references so you can figure out how ruby works.
Are you sure you did it correctly?
Let's take your latest pearl [...]
why don't you try to answer again

I think these qualify as potential violations of the code of conduct, which you can see at https://www.ruby-lang.org/en/conduct/, specifically the second item.

[bughit (bug hit)]

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

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

Looks like you need these context references so you can figure out how ruby works.
Are you sure you did it correctly?
Let's take your latest pearl [...]
why don't you try to answer again

I think these qualify as potential violations of the code of conduct, which you can see at https://www.ruby-lang.org/en/conduct/, specifically the second item.

You have posted a bunch of confused nonsense here. First you wanted to dupe this on the premise the Module.nesting[0] == "default definee". Then you claimed the user doesn't need to think about the "default definee" because Ruby is thinking about it for them. And when your nonsense is called out, you reach for the ban button. What a shock.

[ioquatix (Samuel Williams)]

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 values can reduce the cost of the method call. I think such a feature can be reasonable, however I'd suggest you follow the standard feature request template (e.g. update this issue). I believe this may address the performance concerns but I admit I don't fully understand the use case.

https://bugs.ruby-lang.org/projects/ruby/wiki/HowToRequestFeatures provides details about the feature request template. Even if it's just a simple feature request, it will help us triage your request and discuss it further.

[bughit (bug hit)]

ioquatix (Samuel Williams) wrote in #note-12:

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

You appear to be commenting on #19644, not this one (#19682), so I'm going to respond there.

[Eregon (Benoit Daloze)]

@matz (Yukihiro Matsumoto) Could you take a look at https://bugs.ruby-lang.org/issues/19682#note-10?
This user is also intentionally misinterpreting my comments to do personal attacks (e.g. https://bugs.ruby-lang.org/issues/19682#note-11), I think that alone is a clear violation.
I think such behavior is unacceptable on the mailing list/bug tracker.
AFAIK I never did personal attacks to @bughit (bug hit) and kept it civil.
I think disabling his account on the bug tracker is an appropriate action here.
It is unfortunate it would come to that, but that has gone too far already, see below.

It is also not the first time that I and others too feel that @bughit (bug hit) is disrespectful on this issue tracker, many of his issues are not phrased in an appropriate tone:

• I recall https://bugs.ruby-lang.org/issues/18461#note-9, e.g. "There no logic in this conclusion" feels needlessly aggressive, especially when that user is missing the point about compatibility and aliasing eval
• https://bugs.ruby-lang.org/issues/11779#note-20 and later feels needlessly aggressive to @shugo (Shugo Maeda)
• https://bugs.ruby-lang.org/issues/11256#note-21 "incoherent restriction that cannot be justified logically" is basically an aggressive way to say @jeremyevans0 (Jeremy Evans) 's reply makes no sense (and it does make sense of course).
• https://bugs.ruby-lang.org/issues/10450#note-13 and https://bugs.ruby-lang.org/issues/10450#note-25 are needlessly aggressive to @duerst (Martin Dürst). This is another clear personal attack and disrespectful behavior.
• and probably more, sometimes it's rather subtle or needs multiple replies to realize why the tone is not appropriate, I listed the obvious ones I could find here.

I also feel this user is arrogant, notably he often writes he knows better than CRuby committers about Ruby, yet AFAIK he never did contribute to ruby/ruby.
Notably https://bugs.ruby-lang.org/issues/18461#note-9 where he thinks it's OK to break tons of compatibility and won't even consider it an argument or https://bugs.ruby-lang.org/issues/10450#note-22 where he does not listen for how to get progress on an issue.

It also feels to me this user is not interested in a productive discussion on the tracker, we have asked many times for a concrete example with Ruby code but he does not bother and pretends to know better (e.g. #17721, #19682, #19644, #12129, #10778, https://bugs.ruby-lang.org/issues/10450#note-22, etc). I think filing issues without a concrete example and not adding one when asked is just wasting everybody's time, and a form of spam.

[bughit (bug hit)]

Eregon's attempts to respond to this ticket have been invalid and obstructionist.

First he tried to close it as a dupe because in his mind Module.nesting[0] is the "default definee". Then he argued that the user does not need to think about the "default definee", its just for Ruby to keep track of.

Since he evidently has the power to close tickets, I'm forced to waste my time defending against his nonsense, lest it remain the final verdict leading to closure.

He then moved on to off-topic spam and has finally derailed this issue. It's no longer about the "default definee", but his quest to get me banned. If the purpose of this tracker is to evaluate bug reports and feature requests on their merits, it's his invalid and off-topic posts that are getting in the way here.

If this feature request is to be rejected, it should be with the full awareness of what "default definee" is and why it matters to the user. Not with ignorant misconceptions.

[austin (Austin Ziegler)]

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

If this feature request is to be rejected, it should be with the full awareness of what "default definee" is and why it matters to the user. Not with ignorant misconceptions.

Could you ELI5 what a "default definee" is, why it would be useful, and perhaps give examples of how it would be used? I’ve been using Ruby for 21 years and done lots of metaprogramming and … I have absolutely no clue what you’re talking about in this ticket. If it’s an "important context", it should be easy to explain how it would be used and convince people that this suggestion has merit.

[bughit (bug hit)]

austin (Austin Ziegler) wrote in #note-16:

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

If this feature request is to be rejected, it should be with the full awareness of what "default definee" is and why it matters to the user. Not with ignorant misconceptions.

Could you ELI5 what a "default definee" is, why it would be useful, and perhaps give examples of how it would be used?

The explanation of "default definee" is in the blog article linked in the OP, which you have not read for some reason, despite wanting to discuss it.

I’ve been using Ruby for 21 years and done lots of metaprogramming and … I have absolutely no clue what you’re talking about in this ticket.

You almost seem to be saying that with pride. Well ok, congrats on that.

[bughit (bug hit)]

In general I would add that there are other implicit contexts in ruby that are not obvious or intuitable in various meta-programming scenarios. They are "default definee" (method definition), constant definition (cref I think) and class variable (@@) definition. I don't think their metaprogramming behavior is well documented, so there's good reason for ruby to help with identifying them explicitly. "default definee" starts lexical but can be shifted dynamically (class_eval, instance_eval, ...). Constant definition might be fully lexical and @@ I don't remember anything about from some experimentation long ago.

I didn't include ivar definition as I believe that's the simplest and best understood context, fully dynamic, relative to self, AFAIK. But the point here is, there's variance among the implicit contexts and hybrid (lexcial/dynamic) behavior is possible for some, so collectively its not trivial to keep this all in your head on instant recall, there's definitely opportunity for forgetting/confusing.

[austin (Austin Ziegler)]

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

austin (Austin Ziegler) wrote in #note-16:

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

If this feature request is to be rejected, it should be with the full awareness of what "default definee" is and why it matters to the user. Not with ignorant misconceptions.

Could you ELI5 what a "default definee" is, why it would be useful, and perhaps give examples of how it would be used?

The explanation of "default definee" is in the blog article linked in the OP, which you have not read for some reason, despite wanting to discuss it.

I’ve read the article. It seems interesting but not useful. How would having easy access to the default definee help me write better Ruby meta programming?

If you’re convinced that this is such a good idea, you should be able to demonstrate a use case trivially. As you’ve been asked to do multiple times.

I’ve been using Ruby for 21 years and done lots of metaprogramming and … I have absolutely no clue what you’re talking about in this ticket.

You almost seem to be saying that with pride. Well ok, congrats on that.

No. I’m just saying that you seem to think that you know better than people who have been implementing Rubies for a very long time and people who have done a lot of work with Ruby…and won’t come up with a simple example of how access to this implementation detail (I’m not sure that any version of Ruby except MRI would need to implement things this way) would make it easier to solve real problems.

This, and your immediate combativeness across multiple tickets, is what has caused the current issue to spiral.

For what it’s worth, starting a ticket with a link isn’t necessarily the best way to convince people. I think that you could have gotten better traction with something like:

In 2009, Yugui described the difference between self and the “default definee” https://blog.yugui.jp/entry/846. This context seems pretty important, so why not make it easy to identify?

Then you could have gone into what benefit access to that context would provide so that the suggestion could be measured on the merit of benefit, even if that benefit is better specifying behaviour for future Ruby implementations.

Not hard, not combative.

Frankly, the blog post didn’t even register because I read these through the mailing list and it is right below some Redmine ticket cruft.

If you do happen to be smarter than everyone else, try assuming that you need to help people understand, rather than assuming that they’re too stupid to possible ever understand. You’ll get more accomplished.

[ioquatix (Samuel Williams)]

• Status changed from Open to Rejected

Without a clear specification, we cannot implement this feature. I'll consider opening a new one with a specific proposal around Module#nesting(n).

[bughit (bug hit)]

ioquatix (Samuel Williams) wrote in #note-20:

Without a clear specification, we cannot implement this feature.

A clear specification of what? "default definee" is quite clear in ruby internals, it has to be, there can be no ambiguity about where methods are defined. This issue is about exposing it, so what is unclear? How to expose it? "Could be a Module class method or a global method (Kernel) or a keyword."

I'll consider opening a new one with a specific proposal around Module#nesting(n).

What does this have to do with Module#nesting(n)? Why are you still conflating #19644 and #19682?

[rubyFeedback (robert heiler)]

bughit wrote:

"default definee" is quite clear in ruby internals

The internals are not necessarily what ruby "shows" to a user/developer though.

The question here is how a ruby user refers to it. It's a bit difficult to
explain, but you can review what matz said over the years - from the old
article "The Philosophy of Ruby"
https://www.artima.com/articles/the-philosophy-of-ruby in 2003, but also
in other issue discussions. See the suggestions to create Hashes with a
definite / default / max-size. Either way it can change the way how people
write code or think about problems.

For instance, I actually do not recall matz using the word "default definee".
In the blog entry you linked to from 2009 or so, the author arbitrarily
reasoned that "klass" should be called "defined definee":

Specifically this part:

I called the conception `klass' in the old article but it might
not be a good name. It is the default class onto which method
is defined. Now I'd like to call it "default definee".

I am not convinced that this is a good renaming effort. It can cause
confusion for ruby users. For instance, what is the difference between
a class, a klass, an eigenklass, self, a default definee, a singleton?

We should ideally make concepts simpler to understand. I don't think
adding the terminology "default definee" helps here; new ruby users
may wonder what the difference to "self" is.

I understand that part of your argument is that it is not easy to
see where self is right now, e. g. where self "points at" (this is
how I try to remember it actually). I myself always mix up .instance_eval
with .class_eval, so I am not completely disagreeing with your rationale
either. There is room for simplification, if we could ignore backwards
compatibility - I am not against that. I just don't think that using
the terminology "default definee" really helps here.

there can be no ambiguity about where methods are defined. This
issue is about exposing it, so what is unclear? How to expose
it?

This presupposes that we SHOULD expose it, and I am not entirely certain
that this should be the case. You could consider suggesting this to
an upcoming dev meeting, if only to ask matz and the core team about
it (if you want to, as a follow-up to that old blog entry).

I think having a new keyword may also be problematic as it is harder to
change/remove, so if at all having it as a method may be better. But
I am not sure it should be added really. To me this is more a language
design consideration.

[ioquatix (Samuel Williams)]

A clear specification of what? "default definee" is quite clear in ruby internals, it has to be, there can be no ambiguity about where methods are defined. This issue is about exposing it, so what is unclear? How to expose it? "Could be a Module class method or a global method (Kernel) or a keyword."

I would suggest opening a new issue, following the feature request template, provide exact details of the interface you are proposing to introduce (e.g. __module__ or nesting(0)), the scenarios where it's useful, and if it's simple enough, a PR which shows the proposed implementation. My advice is to come from the angle of "is this a useful feature?" and explaining why you think it's useful with example code or references to existing code that could be simplified with the proposed feature. If people ask questions, focus on the technical content.

is quite clear in ruby internals, it has to be, there can be no ambiguity about where methods are defined.

While this may be true from an implementation POV, it may be accidental behaviour or underspecified/under-documented. So, I'd be extremely clear about the definition of such a feature. If you truely think this is already clearly defined in terms of CRuby, then please make a reference to the current implementation (i.e. C function).

This issue is about exposing it, so what is unclear? How to expose it? "Could be a Module class method or a global method (Kernel) or a keyword."

Yes, it's unclear how you propose to expose it. Without example use cases, we cannot judge which approach would make the most sense, nor can we know the impact or value of the proposal.

• If you propose to introduce something which introduces a new interface, it will be more difficult to accept. e.g. __module__.
• If you propose a small change to an existing interface, it can be easier to accept. e.g. nesting(n_or_range).

My advice is to make a specific proposal that best suits your use-case. Showing that it has a benefit to existing real-world code with real examples will help people understand your proposal. Being adversarial and confrontational with people will work against your proposal.

[matz (Yukihiro Matsumoto)]

“why not” is not enough. If there are real-world use-cases, we might reconsider in the future.
In addition, I don't like the tone of this discussion. I want us to keep calm even when we have communication difficulties.

Matz.

[bughit (bug hit)]

ioquatix (Samuel Williams) wrote in #note-23:

I'll consider opening a new one with a specific proposal around Module#nesting(n).
provide exact details of the interface you are proposing to introduce (e.g. __module__ or nesting(0))

• If you propose to introduce something which introduces a new interface, it will be more difficult to accept. e.g. __module__.
• If you propose a small change to an existing interface, it can be easier to accept. e.g. nesting(n_or_range).

I've asked you this already, why are you continuing to talk about Module::nesting in this issue? Do you still not understand that "default definee" is not Module.nesting[0]?

[bughit (bug hit)]

rubyFeedback (robert heiler) wrote in #note-22:

The question here is how a ruby user refers to it.

What to name it is of secondary importance. This issue is about exposing it, I did not even suggest a name. For the purpose of discussion I am referring to it as "default definee" because that blog article is the only place I am aware of that documented the concept. If it's documented and named better elsewhere, great, let's see it. Until exposing it is settled on in principle, its pointless to argue about naming.

This presupposes that we SHOULD expose it, and I am not entirely certain

Since it very much matters to the user where their methods end up, it should be possible for them to easily discover this context. This helps ruby be self documenting and helps the user learn the language. Any argument against it, unavoidably becomes at its core: lets keep ruby difficult to understand and learn.

Any insinuation of the kind that, its a difficult concept that should be swept under the rug, is preposterous. The concept exists in ruby and affects user code, whether one likes it or not. You can chose to ignore it and stick to only simple and clear uses of def, but that shouldn't preclude others from understanding (with the help from ruby) the more complex ones. And exposing helps with that.

I understand that part of your argument is that it is not easy to see where self is right now

"default definee" is not self, its also not the currently open module (Module.nesting[0]). Its more tricky. The fact that this is far from obvious to many/most, is the very justification for exposing it. It looks like no one who responded here (excluding matz), understands it fully, and yet are convinced that no assistance from ruby is justified. Let's go through the list:

• Eregon
  • thinks its Module.nesting[0]
  • thinks the user doesn't need to think about it, its just for Ruby to worry about
• ioquatix
  • appears to be conflating it with Module.nesting[0]: "I'll consider opening a new one with a specific proposal around Module#nesting(n)"
• austin
  • "I’ve been using Ruby for 21 years and done lots of metaprogramming and … I have absolutely no clue what you’re talking about in this ticket."
• rubyFeedback
  • conflating it with self

Without realizing it you have all made my case.

[bughit (bug hit)]

matz (Yukihiro Matsumoto) wrote in #note-24:

“why not” is not enough. If there are real-world use-cases, we might reconsider in the future.

Where do you see "why not" as a justification?

See my previous message. What is your assessment, do these posters understand "default definee" (method definition context)? I see no evidence of it. Even ruby contributors, with ticket rejection privileges, who should know better, keep conflating it with Module.nesting[0] and saying things like "these things are things Ruby needs to track internally, but the user probably has no need for" and "it may be accidental behaviour or underspecified". Can you believe what you're reading, matz? Turns out a ruby programmer doesn't need to think about where their methods are defined. In fact you probably should not use def at all as the method definition context may be accidental/undefined behavior, so perhaps your methods will jump around from time to time. This is what obscuring the method definition context has wrought.

It's clear that exposing the "default definee" would help users understand ruby better. I would have thought that is your objective, but if you want to keep it mysterious, well, so be it, its your language.

[matz (Yukihiro Matsumoto)]

Where do you see "why not" as a justification?

From your first proposal.

"default definee" is a pretty important context so why not make it easy to identify?

Matz.

[bughit (bug hit)]

matz (Yukihiro Matsumoto) wrote in #note-28:

Where do you see "why not" as a justification?

From your first proposal.

"default definee" is a pretty important context so why not make it easy to identify?

Matz.

That is just a turn of phrase, its not the substance of the argument. Can we focus on the substance? I've posted a lot of clarification, is it fair to dismiss it all as no justification other than "why not"?

When a user uses def in various metaprogramming contexts, where that method ends up, depends on the current "default definee". And what it is, is not necessarily always obvious. The various rules for how the "default definee" shifts, both lexically and dynamically are in the blog linked in the OP. I wouldn't call them intuitable, you need to understand and remember them.

In general I would add that there are other implicit contexts in ruby that are not obvious or intuitable in various meta-programming scenarios. They are "default definee" (method definition), constant definition (cref I think) and class variable (@@) definition. I don't think their metaprogramming behavior is well documented, so there's good reason for ruby to help with identifying them explicitly. "default definee" starts lexical but can be shifted dynamically (class_eval, instance_eval, ...). Constant definition might be fully lexical and @@ I don't remember anything about from some experimentation long ago.

But the point here is, there's variance among the implicit contexts and hybrid (lexcial/dynamic) behavior is possible for some, so collectively its not trivial to keep this all in your head on instant recall, there's definitely opportunity for forgetting/confusing.

Since it very much matters to the user where their methods end up, it should be possible for them to easily discover this context. This helps ruby be self documenting and helps the user learn the language. Any argument against it, unavoidably becomes at its core: lets keep ruby difficult to understand and learn.

The concept exists in ruby and affects user code, whether one likes it or not. You can chose to ignore it and stick to only simple and clear uses of def, but that shouldn't preclude others from understanding (with the help from ruby) the more complex ones. And exposing helps with that.

"default definee" is not self, its also not the currently open module (Module.nesting[0]). Its more tricky. The fact that this is far from obvious to many/most, is the very justification for exposing it. It looks like no one who responded here (excluding matz), understands it fully, and yet are convinced that no assistance from ruby is justified.

What is your assessment, do these posters understand "default definee" (method definition context)? I see no evidence of it. Even ruby contributors, with ticket rejection privileges, who should know better, keep conflating it with Module.nesting[0] and saying things like "these things are things Ruby needs to track internally, but the user probably has no need for" and "it may be accidental behaviour or underspecified". Can you believe what you're reading, matz? Turns out a ruby programmer doesn't need to think about where their methods are defined. In fact you probably should not use def at all as the method definition context may be accidental/undefined behavior, so perhaps your methods will jump around from time to time. This is what obscuring the method definition context has wrought. It's clear that exposing the "default definee" would help users understand ruby better.

[matz (Yukihiro Matsumoto)]

You have explained the concept of (existence of) “default definee”. I personally don't use that particular term, but I understand the intention.
As far as I understand, you haven't explained the need for a method to retrieve the “default definee”. I don't agree with having a method just to “help users understand ruby better”.

I agreed with the rejection of this proposal for several reasons:

• This proposal does not have real-world use-cases
• We don't have consensus regarding the term to describe the concept
• This proposal is incomplete without a concrete method name.

Matz.

[Eregon (Benoit Daloze)]

• Related to Feature #19644: Module::current to complement Module::nesting added