From: "jeremyevans0 (Jeremy Evans) via ruby-core" <ruby-core@...>
Date: 2024-02-28T15:38:17+00:00
Subject: [ruby-core:116994] [Ruby master Feature#20309] Bundled gems for Ruby 3.5

Issue #20309 has been updated by jeremyevans0 (Jeremy Evans).


Eregon (Benoit Daloze) wrote in #note-6:
> hsbt (Hiroshi SHIBATA) wrote:
> > * singleton
> > 	* This is famous design pattern. Should we enforce users add them to their Gemfile?
> 
> IMO not worth it, it's pretty [trivial code](https://github.com/ruby/ruby/blob/master/lib/singleton.rb) and too much overhead to ask users to add to Gemfile for something so basic.

On the other hand, it's almost always better to use a normal constant with a singleton object than the `singleton` library.  `singleton`'s only advantage is you can delay initialization, and if you want that, you can use `autoload` for the file that defines the constant.

Instead of:

```ruby
class Klass
  include Singleton

  # define methods
end

Klass.instance
```

Use:

```ruby
CONSTANT = Object.new
CONSTANT.singleton_class.class_eval do
  # define methods
end
```

I think we should encourage users to use the singleton object support built into Ruby core, as opposed to a separate library that accomplishes mostly the same thing.  I think the main advantage of the `singleton` library over standard Ruby is that it supports marshalling, but I'm not sure how common is the need to marshal singleton objects.

I'm in favor of moving the `singleton` library to bundled gems mainly to discourage users from using it.

----------------------------------------
Feature #20309: Bundled gems for Ruby 3.5
https://bugs.ruby-lang.org/issues/20309#change-107051

* Author: hsbt (Hiroshi SHIBATA)
* Status: Assigned
* Assignee: hsbt (Hiroshi SHIBATA)
----------------------------------------
I propose migrate the following default gems to bundled gems at Ruby 3.5. So, It means users will get warnings if users try to load them. 

* ostruct
  * I make ostruct as optional on json at https://github.com/flori/json/pull/565 
* irb
  * We need to consider how works `binding.irb` after Ruby 3.5.
* reline
* readline (wrapper file for readline-ext and reline)
* io-console
* logger
* fiddle
* pstore
* open-uri
* yaml (wrapper file for psych)
  * syck is retired today. I'm not sure what people uses `psych` directly, not `yaml`.
* win32ole

I have a plan to migrate the following default gems too. But I need to more feedback from other committers about them.

* rdoc
	* We need to change build task like download rdoc gem before document generation.
	* or We make document generation is optional from Ruby 3.5
		* We explicitly separate `make install` and `make install-doc`
* un
	* `ruby -run` is one of cool feature of Ruby. Should we avoid uninstalling `un` gem?
* singleton
	* This is famous design pattern. Should we enforce users add them to their Gemfile?
* forwadable
	* `reline` needs to add forwardable their `runtime_dependency` after migration.
* weakref
	* I'm not sure how impact after migrating bundled gems.
* fcntl
	* Should we integrate these constants into ruby core?

I would like to migrate `ipaddr` and `uri` too. But these are used by webrick that is mock server for our test suite. We need to rewrite `webrick` with `TCPSocker` or extract `ipaddr` and `uri` dependency from `webrick`

Other default gems depend on our build process or other libraries deeply.  I will update this proposal if I could extract them from default gems.



-- 
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/