On May 23, 2006, at 2:28 PM, Chuck Hill wrote:Thanks for taking the time out of your weekend to help me with the qualifier statement. So, enough with this WO stuff, anyone have advice on getting a baby with a cold to sleep? If we knew how to do that, I doubt we would still be working for a living
Mark and Chuck.
Thanks for the words of empathy. On top of all that, she got her shots
and is teething. Such a poor little thing.
Ok, both of your emails have finally gotten through my thick skull.
And Chuck hit the nail on the head. I was trying to get the values
before they were stored
Hi Reid,
On May 23, 2006, at 10:27 AM, Reid Bundonis wrote:
Ken, Mark, and Chuck,
Thanks for taking the time out of your weekend to help me with the
qualifier statement. So, enough with this WO stuff, anyone have
advice on getting a baby with a cold to sleep?
If we knew how to do that,
Hello Reid,
First of all, I hope your child feels better soon. :-) I have been
through that phase with 3 of my own, so I can empathize.
Ok, let's look at what you have below:
On May 23, 2006, at 12:27 PM, Reid Bundonis wrote:
Ken, Mark, and Chuck,
Thanks for taking the time out of your w
Ken, Mark, and Chuck,
Thanks for taking the time out of your weekend to help me with the
qualifier statement. So, enough with this WO stuff, anyone have advice
on getting a baby with a cold to sleep? If the rest of this post in
incoherent, I apologize in advance. Sleep deprivation and WO
d
Hi, Mike,
Your second test results sound good in several ways:
* the times of the second test sound a lot more realistic overall
than those of the first
* the difference between times of valueForKey and valueForKeyPath
is a lot closer to what I would expect than in the first test (a fe
Good catch ... You are correct that it was actually returning a
constant value and probably was being JIT'd away. I'm on a 2Ghz
MacBook Pro, by the way.
Here are the results of the slightly modified test that returns
constant string + System.currentTimeMillis() AND uses -Xint to
disable
Hi, Mike, et al,
Thanks for testing that, but I think there might be something wrong
with the test, and I suspect it might have something to do with
optimizing compilation.
From what you've said, your test is indicating that valueForKeyPath
takes( (992 - 935) / 1000) / 1,000,000 of a sec
Yes that was the comparison I was looking for --- the first two are
really the test, the 3rd i threw in just out of curiosity with the
caveat that there's not enough data to know if it's just .length that
it slow or whether there's a substantial overhead just traversing
"one more keypath".
I think the test is reasonably valid - the question being tested was,
is there a penalty for always using valueForKeyPath(). Under what
circumstances would you not want to?
On May 22, 2006, at 4:27 PM, Wolfram Stebel wrote:
Am 22.05.2006 21:51 Uhr schrieb "Mike Schrag" unter
<[EMAIL PROTE
Am 22.05.2006 21:51 Uhr schrieb "Mike Schrag" unter
<[EMAIL PROTECTED]>:
Hello Mike,
i dont think that that your arguments for "use always key path" are valid.
I think there is a difference in calling "length" as a method on String
instead of following a relation, a more important reason that
"va
Technically speaking, you can ALWAYS use valueForKeyPath and it will
work. Obviously valueForKey does not have that attribute.
So the question is performance ... I've kind of wondered this before
also. So in the spirit of knowing-is-half-the-battle:
I have an object with one method "publi
Chuck Hill wrote on 5/21/06 11:44 AM:
>> NSArray bindings = new NSArray( new Object [] {
>> (Session)session().valueForKey("user.client.clientName") } );
>>
> valueForKeyPath not valueForKey
I've been bitten by this one too.
Is there ever a reason to use valueForKey instead of valueForKe
Ach! Skimmed right over that one. :-) And you'd have thought
valueForKeyPath would have been on my mind, as it just came up in a
post last night
-- Mark
On May 21, 2006, at 10:44 AM, Chuck Hill wrote:
On May 21, 2006, at 2:06 AM, Reid Bundonis wrote:
NSArray bindings = new NSArr
On May 21, 2006, at 2:06 AM, Reid Bundonis wrote:
All,
Forgive me for asking what should be obvious (it is the weekend and
I left the books at the office, I am a new dad which equals no
sleep and brain dead, and the dog ate my homework).
I am trying to construct an EOQualifier to grab a
Sorry, I meant if user is a public variable or accessor, not client, in the second paragraph below.-- Mark On May 21, 2006, at 9:59 AM, Mark Morris wrote:Hello Reid,Ken's post has already pointed out how your approach, on the surface anyway, raises a little warning flag. The code for what he's tal
Hello Reid,Ken's post has already pointed out how your approach, on the surface anyway, raises a little warning flag. The code for what he's talking about would be something like: NSArray bindings = new NSArray( session().valueForKey("user.client") ); qual = EOQualifier.qualifierWithQualifierForma
Reid,Just so I understand what you want to do - you're trying to fetch Process records from the database for the client, right?My first question is, since you say you have a client object, why are you using the clientName instead of the client object? You should really have a relationship in Proce
18 matches
Mail list logo
