[ruby-core:122073] [Ruby Bug#21334] Namespaces and object reference sharing

Issue #21334 has been updated by fxn (Xavier Noria).


I have spent countless hours of my free time on namespaces in the last days. I experimented with the feature again tonight, and wrote this ticket with care, looking for edge cases, and presenting them.

While rejecting on that basis is your call, I am truly disappointed by this reaction.

The thought experiments are clear, please consider them at your own discretion, I won't open any other ticket.

----------------------------------------
Bug #21334: Namespaces and object reference sharing
https://bugs.ruby-lang.org/issues/21334#change-113226

* Author: fxn (Xavier Noria)
* Status: Rejected
* Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN
----------------------------------------
# Implications related to builtin classes and modules

As we know, when a namespace is created, builtin classes in the namespace are as in the root one. This applies to all references to them, explicit or implicit.

This is at the core of the current implementation and semantics of namespaces.

However, the feature also allow object references to cross namespaces. For example, via method calls:

```ruby
ns::Foo.m(ref)
```

And this has implications that do not seem good to me. Examples:

1. If `ref` has an HTTP client in an attribute, that depends on a parser gem, which depends on a string utils gem, that adds `blank?` to `String`, that call is broken because the transitive code at some point may perhaps hit a `blank?` call, and the user has no way to tell.

2. If `ref` is a reference created by a gem managed by Zeitwerk (there are hundreds), the call is broken too. When `m` uses `ref`, it might need to lazy load something, and that won't work because the [Kernel#require](https://github.com/fxn/zeitwerk/blob/main/lib/zeitwerk/core_ext/kernel.rb) and [Module#const_added](https://github.com/fxn/zeitwerk/blob/main/lib/zeitwerk/core_ext/module.rb) decorations are gone within the namespace.

Please, note whether a gem loads with Zeitwerk or not is transparent to the user of the gem, by design. How do gems load their code is a private matter that is not, and should not be, documented. So the user does not know.

# Implications related to different gem versions

In the example above, `ref` could be an instance of an object that corresponds to v2.0 of a gem, and perhaps the code under the namespace has a transitive dependency on v1.0. Mixing such references seems like a receipt for a good amount of Paracetamol.

# Proposal

This is all so brittle, that I would like to ask for a fundamental reconsideration of cross-namespace object reference passing.

The rules are consistent within a namespace, problem is opening that up to cross-namespace communication.

Maybe redefine communication across namespaces in a very restrictive way that make these issues by design. Maybe remove cross-namespace communication in this manner altogether. Or some other option people can think of.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/