Re: Generic "valueForKeyAsArray" in NSKeyValueCoding spec
Re: Generic "valueForKeyAsArray" in NSKeyValueCoding spec
- Subject: Re: Generic "valueForKeyAsArray" in NSKeyValueCoding spec
- From: Lachlan Deck <email@hidden>
- Date: Mon, 14 Jan 2008 13:41:16 +1100
On 14/01/2008, at 1:23 PM, Gaastra Dennis - WO Lists wrote:
Pierre, how about:
public NSArray<?> valueForKeyAsArray(String key)
public void takeValueForKeyAsArray(NSArray<?> array, String key)
Sounds like that would lead to a _lot_ of accompanying methods which
wouldn't be nice IMO.
in NSKeyValueCoding specifictions
It seems to me that the whole point of generics is to guarantee at
compile time a certain casting. I don't see the benefit of the above
apart from saving you a cast in code (and complicating the api)
seeing as [take]ValueForKey cannot determine until runtime if 'key'
is of type NSArray.
What Anjo was suggesting seems to make more sense and it has the
added benefit of sitting alongside the current implementation due to
the simple change in parameter.
public Object valueForKey(String key);
public T valueForKey(Key<T> key);
Still I don't see how this is going to benefit on the whole anyway
(apart from auto-generated classes like the models) seeing as
NSKeyValueCoding.Utility and friends still allows you to follow
keyPaths over objects that will simply not provide a 'Key' compatible
interface.
There's a point where generics just has to stop (as Art mentioned).
But where it makes sense to use it's very helpful.
On 13-Jan-08, at 6:11 PM, Lachlan Deck wrote:
On 14/01/2008, at 12:53 PM, Mr. Pierre Frisch wrote:
Actually a raw fetch return a
NSArray<NSDictionary<String, ?>>
Ah yes. So does this work for you in EOEditingContext along with
the previous suggestion for the current api?
public NSArray<NSDictionary<String, ?>>
rawObjectsWithFetchSpecification(EOFetchSpecification fetchSpec)
{....}
Pierre
--
Pierre Frisch
email@hidden
On Jan 13, 2008, at 15:19, Lachlan Deck wrote:
Slight correction...
On 14/01/2008, at 8:48 AM, Lachlan Deck wrote:
Actually, having thought about it a bit more, I think it's not
such a nice improvement. i.e., it's not the user that
determines what type of object is returned for a raw-row fetch;
that's a function of the framework.
So the only way I can see this moving forward:
* deprecate the flag in EOFetchSpecification
* adjust EOEditingContext as follows...
public NSArray<T> objectsWithFetchSpecification
(EOFetchSpecification<T> fetchSpec) {...}
public NSArray<?> rawObjectsWithFetchSpecification
(EOFetchSpecification fetchSpec) {....}
(Seeing as raw fetches can return an Integer, Long, String,
NSDictionary depending on the query/calculation)
What do you think?
with regards,
--
Lachlan Deck
On 09/01/2008, at 6:13 AM, Mr. Pierre Frisch wrote:
This would be a pretty radical change that would break a lot
of code. At the moment the raw rows is a boolean in the
EOFetchSpecification, I agree that this would be a nice
improvement but are we ready for it?
Pierre
--
Pierre Frisch
email@hidden
On Jan 7, 2008, at 20:03, Mike Schrag wrote:
.... pretend .... you ... never mentioned that?
I suppose your fetch spec would then be
EOFetchSpecification<NSDictionary> and maybe it would just
work out?
ms
On Jan 7, 2008, at 10:04 PM, Mr. Pierre Frisch wrote:
And what do you do with raw rows?
Pierre
--
Pierre Frisch
email@hidden
On Jan 7, 2008, at 7:36, Mike Schrag wrote:
NSArray<MyEO> = ec.objectsWithFetchSpecification(spec,
MyEO.class)
I think generic EOFS would be better ... Passing in Class
objects to fulfill generics always feels a bit like
hackery. It's really cheating -- you're basically casting
without using cast syntax, because you can't enforce that
the class you put in is actually related to the objects of
the fetch spec in any way, so it's as unsafe as an
arbitrary cast.
public <T> NSArray<T> objectsWithFetchSpecification
(EOFetchSpecification<T> fetchSpec) { ... }
then
EOFetchSpecification<Person> fetchSpec = ...;
NSArray<Person> people = ec.objectsWithFetchSpecification
(fetchSpec);
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-
email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
with regards,
--
Lachlan Deck
_______________________________________________
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