Re: locations of DST information
Re: locations of DST information
- Subject: Re: locations of DST information
- From: Chuck Hill <email@hidden>
- Date: Mon, 28 Jan 2008 20:52:41 -0800
On Jan 28, 2008, at 3:38 PM, Mr. Pierre Frisch wrote:
Actually this is my argument to dump NSTimestampFormatter, it is an
implementation and it is quite a bad one at that.
No. No it is not. Is part of the NSFoundation abstraction and API.
It has been for, well, a long time. Its current implementation
might be bad, but that is not a valid reason to discard the
abstraction and chop out part of the API. If the implementation is
bad, fix the implementation. Make it subclass SimpleDateFormat,
whatever.
For once SimpleDateFormat is a much better, format definition is
clearer and more flexible, localized version works. So much so that
if I am not mistaken the examples in Practical WebObjects use the
Simple Date Format syntax.
They might use the formatter symbols, but they still use
NSTimestampFormatter.
I understand everyone concern about existing code and I will take
this into account, but that does not mean we will resurrect
deprecated code.
Honestly, I don't think deprecating was the right decision in the
first place. Gimme back my API, I was using that! :-)
Chuck
On Jan 28, 2008, at 15:09, Chuck Hill wrote:
On Jan 28, 2008, at 1:41 PM, Guido Neitzer wrote:
On 28.01.2008, at 14:00, email@hidden wrote:
I mean, c'mon. Why don't you just deprecate mutable and
immutable Arrays, dicts, etc. Java sort of has those data
structures too. Why duplicate the code? .... see what I mean?
Where do you draw the line? When are we supposed to remember to
use the NeXTSTEP class and when to use some Java or lang du jour
class?
WO, as a framework, is what matters. The language it runs on is
just a vessel.
That is actually one of the best comments in this discussion.
Whether I agree or not to the dateformat discussion in one or the
other way, it seems a little bit to me as if WO is loosing the
focus to be a very nice to use and very intelligently build
framework in favour of adding more and more Java specific oddities.
Yeah, I am kind of ashamed that I did not think of this. :-)
Losing an extensible NSString for String was perhaps unavoidable
as Sun made String final, but this is entirely avoidable.
NSTimestampFormatter is an abstraction. SimpleDateFormat is _an_
implementation.
Most of the Java libraries are just a big, ugly mess of classes,
one not compatible with the other and most of them not intuitive
to use.
That is about the nicest description of them that I have heard. I
am not usually that generous.
We really shouldn't go that route! And, as Apple doesn't really
care about other platforms, why forcing stuff into WO, that is
conceptually incompatible with the existing WO classes AND with
the ideas existent in Cocoa.
cug, just my private opinion as a Cocoa lover and WO developer
I think the abstraction argument is a very strong one. Having
NSArray implement the Java interfaces is the right way to do this
kind of thing. It allows interoperation with 3rd party Java
libraries while keeping the nicer API from NS. Use Java, but keep
the WO abstractions.
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden