Date should be either required or not
Today I was trying to do some experiment with IRB: "Date.today" threw a NoMethodError.
But Date was defined: "defined? Date" == "constant".
If I explicitly required for "date" it worked, but this is pretty much weird. It would be better if either:
- I got an undefined "Date" class instead
- "date" was automatically required
The current state is pretty much misleading.
This also happens in JRuby, so I guess somehow this is an intended behavior, but it doesn't make any sense to me.
#1 Updated by mame (Yusuke Endoh) over 5 years ago
- Status changed from Open to Assigned
- Assignee set to drbrain (Eric Hodel)
This is caused by rubygems/specification:
$ ruby -rrubygems/specification -e 'p Date; Date.today'
<main>': undefined methodtoday' for Date:Class (NoMethodError)
Eric, is this intentional?
Yusuke Endoh firstname.lastname@example.org
#4 [ruby-core:46208] Updated by rosenfeld (Rodrigo Rosenfeld Rosas) over 5 years ago
Is Date that slow to require when compared to Time? Wouldn't it be possible to make it faster to load by lazy loading some parts and include it by default instead of having to require it manually?
That would certainly make programmers happier ;)
#6 [ruby-core:46212] Updated by drbrain (Eric Hodel) over 5 years ago
- Status changed from Assigned to Closed
The pull request was rejected due to its implementation. For compatibility with old gems a Date class must be defined. I decided to switch to require 'date' since rubygems/specification.rb is lazily loaded now and the cost of loading it is low. The commit to rubygems will be imported in the future so I will close this ticket.
Time is part of the core libraries with parsing and extra output formats defined in time.rb. Date exists entirely outside of the core ruby classes so you must require it separately.
Historically Date was much slower than Time due to its implementation. Today that gap is narrower, but Date is still slower than Time. (As a trade-off, Date and DateTime give you a much larger range than a Time.)
Remember, you must require libraries you directly depend on. Do not expect a dependency to load it for you indirectly. This will only lead to bugs and incompatibility as your dependencies change.
#8 [ruby-core:50570] Updated by kommen (Dieter Komendera) about 5 years ago
This is an issue again in Ruby 2.0.0 preview 2 as the require 'date' in rubygems/specification.rb as described in note 6 in this issue was removed again with this commit: https://github.com/rubygems/rubygems/commit/04422c3c7fc0273a5ef9d01641fb0a2a4ee0d03d
I found it to be a backward compatibility issue for example with the compass gem: https://github.com/chriseppstein/compass/blob/stable/compass.gemspec#L6
Should this issue be reopened?
#10 [ruby-core:50588] Updated by drbrain (Eric Hodel) about 5 years ago
I don't know if I can solve this problem with RubyGems.
Date is now a C extension.
At ruby install time, Gem::Specification is loaded by rbinstall.rb which is run from miniruby.
miniruby cannot load C extensions (as mentioned in the commit referenced above).
I'll see if Date can be required only when needed. I believe rbinstall calls ruby_code which uses Date, so it may be difficult.
#11 [ruby-core:50958] Updated by drbrain (Eric Hodel) almost 5 years ago
- Target version changed from 1.9.3 to next minor
I am not clever enough to solve this problem.
As I said before, tool/rbinstall.rb cannot load extensions. If I try to lazy-load Date in lib/rubygems/specification.rb tool/rbinstall.rb obviously, tool/rbinstall.rb fails.
I cannot figure out how to only load Date when RubyGems was not loaded from mini ruby. Attempting to detect the LoadError results in an infinite loop.
Perhaps someone more clever than I can fix this. I will leave it open for now.
#12 [ruby-core:56829] Updated by kommen (Dieter Komendera) over 4 years ago
Just a short update from my side: Since my issue from comment #8 was mostly caused by bad .gemspec files from gems which didn't require 'date' before using it and most (all I know) have been fixed, I think this is not an issue any longer.
Though I still a agree with the original bug report, that this is a strange behaviour.