documented.
Well I guess it all depends on what you consider a random odd function
as opposed to a useful extension. And in the case of GSEncodingName I
think it was filling in a missing feature and it was part of the
additions API. ...but that's history now... :-)
I'd only want to remove (after
Richard Frith-Macdonald schrieb:
On 13 Oct 2006, at 07:25, David Ayers wrote:
Richard Frith-Macdonald schrieb:
As part of the public API, any removal/renaming will go through a
deprecation process ... I have tried to do a two release cycle in the
past (ie if it's marked as deprecated in
On 13 Oct 2006, at 06:17, David Ayers wrote:
Thanks, I've just done this. My main issue was not that it would be
hard to implement, it was a matter of maintaining the mapping together
with the NSStringEncoding enum.
Ah ... that's part of the public API ... the name and value of the
Richard Frith-Macdonald schrieb:
On 13 Oct 2006, at 06:17, David Ayers wrote:
Thanks, I've just done this. My main issue was not that it would be
hard to implement, it was a matter of maintaining the mapping together
with the NSStringEncoding enum.
Ah ... that's part of the public
Hello Richard,
This function returned an non-localized NSString representation of an
NSStringEncoding allowing a way to specify a human readable/set-able yet
locale independent property list representation.
On the one hand it was a documented Function, one which replaced a
deprecated
Hi,
I also vote for a rehabilitation of that function. Otherwise you have to keep a
local copy in the Database
framework or apps like EOModeler. The strings used in EOModels are NOT to be
localised. As such, the
Apple API lacks this functionality, but I am sure they have it hidden...
Dave
On 12 Oct 2006, at 22:30, David Wetzel wrote:
Richard Frith-Macdonald wrote:
I didn't realise this was used outside the base library.
I've no strong objection to putting it back, but I do want to
minimise/remove non-standard APIs (just declaring them private is not
good enough).
Would it
Richard Frith-Macdonald wrote:
Anyway ... as it's used in only one place, why don't I just implement
the function there (gdl2/EOAccess/EOAdaptor.m)?
Any objections?
as it is not database dependent in any way, I would put it into base or base
extensions on platforms where
we use a
On 12 Oct 2006, at 21:13, David Ayers wrote:
Hello Richard,
This function returned an non-localized NSString representation of an
NSStringEncoding allowing a way to specify a human readable/set-
able yet
locale independent property list representation.
On the one hand it was a documented
Richard Frith-Macdonald wrote:
I didn't realise this was used outside the base library.
I've no strong objection to putting it back, but I do want to
minimise/remove non-standard APIs (just declaring them private is not
good enough).
Would it really be a great hardship to just use
Richard Frith-Macdonald schrieb:
I would like to request that we keep this IMHO very useful addition
unless there is some new API that replaces this functionality which I'm
not aware of. At least I'd like to see a deprecation cycle despite the
comment in the header, which I admit I was
11 matches
Mail list logo
