It is just simple as you said.
And it is cool just after I know what's on earthing happening there.
Thanks a lot.
On Fri, Jul 11, 2008 at 2:03 AM, Bill Bumgarner [EMAIL PROTECTED] wrote:
On Jul 10, 2008, at 8:55 AM, an0 wrote:
Sure.
I'm grateful that you tell me the internal truth instead of
I have a NSString * property named `tag' in my class Foo, and use Foo
instances to populate an NSOutlineView. In one delegate method of
NSOutlineView, I pass the `tag' property of an item to a method as an
NSString * argument as follows:
- (void)outlineViewSelectionDidChange:(NSNotification
I ran into this a while back. Basically if the method names only
differ by return type and there is nothing else to go on (like a
concrete object pointer type) the compiler, without complaining,
plumps for the first one it can find, which invariably is Cocoa's
built-in methods and not
Thanks. But isn't it annoying for XCode to pretend to know something
for sure while in fact it is just a wrong guess? At least the warning
is very misleading.
On Thu, Jul 10, 2008 at 9:31 PM, Graham Cox [EMAIL PROTECTED] wrote:
I ran into this a while back. Basically if the method names only
Le 10 juil. 08 à 16:10, I. Savant a écrit :
On Thu, Jul 10, 2008 at 9:49 AM, an0 [EMAIL PROTECTED] wrote:
Thanks. But isn't it annoying for XCode to pretend to know something
for sure while in fact it is just a wrong guess? At least the warning
is very misleading.
How is this XCode's
Hey, that a newcomer spells Xcode XCode (instead of Xcode with a lowercase
c) is not surprising, but that a guy that lies around for a long time and
often gives good advice spell it wrong is not acceptable ;-)
Touché, though I think it should be XCode, (if it's not written in
camel notation,
The return type is certainly part of NSMethodSignature - but as far as
I can tell it's ignored for parsing the Obj-C source and resolving the
method when compiling.
Graham
On 10 Jul 2008, at 11:39 pm, Steve Weller wrote:
On Jul 10, 2008, at 6:31 AM, Graham Cox wrote:
The return type is
We are Cocoa family. I am a RedCocoa, and my elder brother is a
BlackCocoa. We both have a `pet', but our Dad doesn't. My pet is a
Cat, while my elder brother's pet is a Dog. And of course he got his
pet long before me, for he is 10 but I am only 2. So as a Cocoa, am I
supposed to have a pet Dog
On Thu, Jul 10, 2008 at 10:50 AM, an0 [EMAIL PROTECTED] wrote:
We are Cocoa family. I am a RedCocoa, and my elder brother is a
BlackCocoa. We both have a `pet', but our Dad doesn't. My pet is a
Cat, while my elder brother's pet is a Dog. And of course he got his
pet long before me, for he is
You don't say you my pet, you said one of my family member's pet
I'm not wrong if I assume that it's your brother pet.
Just tell the compiler it is your pet and not your brother's on and
it will be happy (see the cast in the following line):
filteredPosts = [[self filterPosts:postNodes
At some point you have to realise that it's a compiler, a very dumb
finite state machine. It can't intelligently recognise every possible
nuance of your code. I agree it's not good behaviour - in my case it
caused a bug that corrupted memory that crashed the program in a
completely
On 10 Jul '08, at 8:19 AM, an0 wrote:
However, if you don't know what exact type of Cocoa I am, how could
you call me BlackCocoa so surely?
Can we stop using confusing metaphors and just talk about OOP? :-p
When the compiler parses a message-send expression ([]) it tries
to figure out
I am with you. We should coldly face the somewhat cold reality.
On Thu, Jul 10, 2008 at 11:26 PM, Graham Cox [EMAIL PROTECTED] wrote:
At some point you have to realise that it's a compiler, a very dumb finite
state machine. It can't intelligently recognise every possible nuance of
your code. I
Actually it doesn't emit a warning.
If you recall my problem a few weeks ago with:
- (float) position;
vs.
- (int) position;
the compiler sailed blithely on without a mention, generating code
that smashed the stack to pieces.
This is different from the situation that does emit a warning,
filteredPosts = [[self filterPosts:postNodes WithTag:[[tagView
itemAtRow:row] tag]] retain];
You don't tell the compiler what is returned by -(id)itemAtRow: so the
compiler doesn't know wether to expect you or your brother. You
should tell it whom to expect and it won't complain
Sure.
I'm grateful that you tell me the internal truth instead of confusing
me even more by just saying it is my responsibility to tell compiler
more.
But if different return types cause different native code, how could
my program still work with the mistaken type(an NSString * returned
from the
Probably because at the machine code level, it's just a value placed
into a register. You get away with it because an object address is 32
bits wide and so is an integer, and both types are passed in the same
register.
G.
On 11 Jul 2008, at 1:55 am, an0 wrote:
But if different return
On 10 Jul '08, at 8:55 AM, an0 wrote:
But if different return types cause different native code, how could
my program still work with the mistaken type(an NSString * returned
from the inner message is treated as an NSInteger at the first place,
then is passed as an NSString * to the outer
Le 10 juil. 08 à 17:52, Graham Cox a écrit :
Actually it doesn't emit a warning.
If you recall my problem a few weeks ago with:
- (float) position;
vs.
- (int) position;
the compiler sailed blithely on without a mention, generating code
that smashed the stack to pieces.
This is
Well, that's the weird thing. I wasn't getting that warning. I was
including both headers, my own usage explicitly using #import, and all
of Cocoa implictly using the precompiled headers. I wonder if that's
how the compiler fails to notice the ambiguity - because of one being
in a
On Thu, Jul 10, 2008 at 9:49 AM, an0 [EMAIL PROTECTED] wrote:
Thanks. But isn't it annoying for XCode to pretend to know something
for sure while in fact it is just a wrong guess? At least the warning
is very misleading.
The warning isn't misleading at all. Xcode is not pretending anything.
It
That's odd.
I did some test. It does not require any warning flags, but for an
undefined reason, gcc does not considere that int and float are
incompatibles.
if you have int and short, int and double, int and long long, int and
NSSize, int and , it logs a warning, but int and float is
Joan Lluch
El 10/07/2008, a las 18:29, Graham Cox escribió:
Well, that's the weird thing. I wasn't getting that warning. I was
including both headers, my own usage explicitly using #import, and
all of Cocoa implictly using the precompiled headers. I wonder if
that's how the compiler
On Jul 10, 2008, at 8:55 AM, an0 wrote:
Sure.
I'm grateful that you tell me the internal truth instead of confusing
me even more by just saying it is my responsibility to tell compiler
more.
But if different return types cause different native code, how could
my program still work with the
On Jul 10, 2008, at 12:44 PM, Michael Ash wrote:
On Thu, Jul 10, 2008 at 9:49 AM, an0 [EMAIL PROTECTED] wrote:
Thanks. But isn't it annoying for XCode to pretend to know something
for sure while in fact it is just a wrong guess? At least the warning
is very misleading.
The warning isn't
On Thu, Jul 10, 2008 at 11:52 AM, Graham Cox [EMAIL PROTECTED] wrote:
Actually it doesn't emit a warning.
If you recall my problem a few weeks ago with:
- (float) position;
vs.
- (int) position;
the compiler sailed blithely on without a mention, generating code that
smashed the stack
On Jul 10, 2008, at 1:29 PM, Michael Ash wrote:
Some experimentation reveals that the compiler is merely extremely
inconsistent about when it warns. For example, int and void warns,
float and void warns, but float and int does not. Double and int
warns, double and float warns, but int and id
On Jul 10, 2008, at 3:29 PM, Michael Ash wrote:
On Thu, Jul 10, 2008 at 11:52 AM, Graham Cox
[EMAIL PROTECTED] wrote:
Actually it doesn't emit a warning.
If you recall my problem a few weeks ago with:
- (float) position;
vs.
- (int) position;
the compiler sailed blithely on without a
On Thu, Jul 10, 2008 at 3:29 PM, Michael Ash [EMAIL PROTECTED] wrote:
I recommend you file a bug with Apple.
And to put my money where my mouth is, I've filed this bug as rdar://6066914
Anyone who's interested in playing with this further may find this
python program useful:
#!/usr/bin/python
On 10.07.2008, at 21:29, Michael Ash wrote:
I can't find
any particular pattern to it, but it's clear that it's a bug, not a
deliberate omission. I recommend you file a bug with Apple.
Your warnings kinda remind me of type promotion. Ints get promoted
to floats, etc.
Cheers,
-- Uli
But most of the time compound statements makes code easier to read.
Why do you think apple included valueForKeyPath instead of only
valueForKey?
On Jul 10, 2008, at 10:26 AM, Graham Cox wrote:
There's no real performance advantage to huge compound statements,
and they definitely make code
On Jul 10, 2008, at 4:25 PM, Matt Burnett wrote:
But most of the time compound statements makes code easier to read.
Why do you think apple included valueForKeyPath instead of only
valueForKey?
The two are completely unrelated.
Key-Value Coding has all kinds of behaviors and heuristics
On Thu, Jul 10, 2008 at 2:17 PM, Brian Stern [EMAIL PROTECTED] wrote:
So I would add For best results, you should avoid using any method name
that is already in use unless its return type and parameters are identical
with the already existing method.
Certainly true. I find this to be less of a
33 matches
Mail list logo
