Stephen,
Do you really think that adding
DateTime toDateTime();
to ReadableInstant would break existing code? It doesn't seem like
that should be the case. Every single implementation of
ReadableInstant already provides a toDateTime method, because that
method is present in AbstractInstant, from which they all inherit.
Adding it to ReadableInstant would only formalize what is already a
de facto feature of the API: every ReadableInstant can convert
itself into a DateTime.
I suppose that if someone else had written an implementation of
ReadableInstant and provided their own toDateTime that returned
something else, then adding toDateTime to ReadableInstant might break
that other person's implementation, but by that standard, no one
could ever add any method to ReadableInstant.
Also, toDateTime can be implemented entirely in terms of the
ReadableInstant public API, which is what AbstractInstant does:
public DateTime toDateTime() {
return new DateTime(getMillis(), getZone());
}
so there don't seem to be any paradigm problems. (Actually that
should probably be getChronology not getZone.) But of course, doing
this myself incurs the cost of constructing a new DateTime every
time, when the ReadableInstant object might already be a DateTime.
Actually, AbstractInstant has a bunch of useful methods that aren't
part of ReadableInstant, such as other toDateTime variants,
toMutableDateTime, and toDate. It seems that adding those to
ReadableInstant could only make the API easier to use for everyone.
Regards,
W
On Aug 22, 2007, at 6:51 PM, Stephen Colebourne wrote:
> Willis Blackburn wrote:
>> The user guide suggests that ReadableInstant has a method called
>> toDateTime:
>>
>>> For maximum flexibility however, you might choose to declare your
>>> method parameters using the Joda-Time interface. A method on the
>>> interface can obtain the concrete class for use within the method.
>>>
>>> public void process(ReadableInstant instant) {
>>> DateTime dt = instant.toDateTime();
>>> }
>>
>> This is, in fact, what I'm trying to do. I've defined my API to
>> accept
>> ReadableInstant. But sometimes I really do want to access fields,
>> so I
>> want to be able to do toDateTime on it. But that method is not
>> present
>> in ReadableInstant.
>
> Oops!
>
>> At first, I thought that it was because Instant doesn't "know" about
>> DateTime, which is further down the class hierarchy. But then I
>> noticed
>> that Instant *does* have a toDateTime method.
>>
>> Can we please have toDateTime in ReadableInstant?
>
> Unfortunately not, as that would be a backwards incompatible
> change. You
> could use a ReadableDateTime, which does have the method, or do new
> DateTime(readableInstant), which is obviously less than ideal.
>
> Note that readableInstant.toInstant().toDateTime() won't work as it
> loses the time zone and chronology.
>
> Stephen
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Joda-interest mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Joda-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/joda-interest
