[#113407] [Ruby master Feature#19630] [RFC] Deprecate `Kernel.open("|command-here")` due to frequent security issues — "postmodern (Hal Brodigan) via ruby-core" <ruby-core@...>

Issue #19630 has been reported by postmodern (Hal Brodigan).

19 messages 2023/05/05

[#113430] [Ruby master Feature#19633] Allow passing block to `Kernel#autoload` as alternative to second `filename` argument — "shioyama (Chris Salzberg) via ruby-core" <ruby-core@...>

Issue #19633 has been reported by shioyama (Chris Salzberg).

16 messages 2023/05/09

[#113489] [Ruby master Bug#19642] Remove vectored read/write from `io.c`. — "ioquatix (Samuel Williams) via ruby-core" <ruby-core@...>

Issue #19642 has been reported by ioquatix (Samuel Williams).

10 messages 2023/05/15

[#113498] [Ruby master Feature#19644] Module::current to complement Module::nesting — "bughit (bug hit) via ruby-core" <ruby-core@...>

Issue #19644 has been reported by bughit (bug hit).

12 messages 2023/05/16

[#113517] [Ruby master Misc#19679] Migrate Wiki from bugs.ruby-lang.org to ruby/ruby GitHub repository — "jemmai (Jemma Issroff) via ruby-core" <ruby-core@...>

Issue #19679 has been reported by jemmai (Jemma Issroff).

11 messages 2023/05/18

[#113529] [Ruby master Bug#19681] The final classpath of partially named modules is sometimes inconsistent once permanently named — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>

Issue #19681 has been reported by byroot (Jean Boussier).

34 messages 2023/05/19

[#113538] [Ruby master Feature#19682] ability to get a reference to the "default definee" — "bughit (bug hit) via ruby-core" <ruby-core@...>

Issue #19682 has been reported by bughit (bug hit).

28 messages 2023/05/19

[#113601] [Ruby master Bug#19687] Should a development version of the standard library be included in ruby/ruby? — "jaruga (Jun Aruga) via ruby-core" <ruby-core@...>

Issue #19687 has been reported by jaruga (Jun Aruga).

9 messages 2023/05/23

[#113632] [Ruby master Bug#19691] Case insensitive file systems, require filename casing — "MSP-Greg (Greg L) via ruby-core" <ruby-core@...>

Issue #19691 has been reported by MSP-Greg (Greg L).

7 messages 2023/05/24

[#113656] [Ruby master Misc#19693] Data initialization is significantly slower than Struct — janosch-x via ruby-core <ruby-core@...>

Issue #19693 has been reported by janosch-x (Janosch M=FCller).

13 messages 2023/05/25

[#113660] [Ruby master Feature#19694] Add Regexp#timeout= setter — "aharpole (Aaron Harpole) via ruby-core" <ruby-core@...>

Issue #19694 has been reported by aharpole (Aaron Harpole).

15 messages 2023/05/25

[#113676] [Ruby master Bug#19697] Resolv::DNS resolution for international domains fails with "Encoding::CompatibilityError: incompatible character encodings: UTF-8 and ASCII-8BIT" — "clairity (claire c) via ruby-core" <ruby-core@...>

SXNzdWUgIzE5Njk3IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGNsYWlyaXR5IChjbGFpcmUgYykuDQ0K

6 messages 2023/05/27

[ruby-core:113654] [Ruby master Feature#19682] ability to get a reference to the "default definee"

From: "bughit (bug hit) via ruby-core" <ruby-core@...>
Date: 2023-05-25 04:45:21 UTC
List: ruby-core #113654
Issue #19682 has been updated by 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.



----------------------------------------
Feature #19682: ability to get a reference to the "default definee" 
https://bugs.ruby-lang.org/issues/19682#change-103297

* Author: bughit (bug hit)
* Status: Rejected
* Priority: Normal
----------------------------------------
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.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

In This Thread