=begin
I ran switch_hitter against home_run's test suites. Most of the failures are due to differences between home_run and the standard library. There are a few failures that I think should be addressed in switch_hitter:
-
Operator methods such as >>, <<, +, and - and methods such as next_day and prev_day should return instances that are the same class of the receiver. This could be complicated as subclasses are generally going to subclass Date and DateTime instead of Date::Light and DateTime::Light. I think it's fair to return a Date::Light for a Date or DateTime::Light for a DateTime, but if the receiver is an instance of a subclass of Date or DateTime, the operator method should return an instance the same subclass.
-
Class methods such as civil, new, commercial, ordinal, and jd should return instances of the class. Similar to 1), Date.new can return Date or Date::Light, but a subclass of Date should return an instance of that subclass.
-
Strings returned by Date or DateTime methods should use US-ASCII encoding by default, or the default internal encoding if set.
-
Date parsing methods such as parse, strptime, httpdate, iso8601, etc. are broken (but the DateTime versions are not).
ruby-head :001 > Date.parse '1/1/2011'
ArgumentError: cannot create
from /home/jeremy/.rvm/rubies/ruby-head/lib/ruby/1.9.1/date.rb:803:in new_l!' from /home/jeremy/.rvm/rubies/ruby-head/lib/ruby/1.9.1/date.rb:803:in
new!'
from /home/jeremy/.rvm/rubies/ruby-head/lib/ruby/1.9.1/date.rb:1081:in new_by_frags' from /home/jeremy/.rvm/rubies/ruby-head/lib/ruby/1.9.1/date.rb:1123:in
parse'
from (irb):1
from /home/jeremy/.rvm/rubies/ruby-head/bin/irb:16:in `'
Related to 1) is that with switch_hitter's design, subclasses of Date and DateTime are not going to have optimized performance. A user would have to subclass Date::Light or DateTime::Light if they wanted their subclass to have optimized performance. I don't really see a way around this without having some Date objects use internal type T_DATA and other Date objects use internal type T_OBJECT, and having a ruby class whose objects can differ in internal type is probably not a good idea.
=end