On Tue, 22 Dec 2009 09:56:33 +1100, Graham Cox graham@bigpond.com
said:
Regarding the use of different completion methods based on manipulating some
common root name, I think that's a bit strange, misguided even.
But when the kind of situation that calls for it arises, it might seem very
On Dec 22, 2009, at 12:58 PM, Matt Neuburg wrote:
On Tue, 22 Dec 2009 09:56:33 +1100, Graham Cox graham@bigpond.com
said:
Regarding the use of different completion methods based on manipulating some
common root name, I think that's a bit strange, misguided even.
But when the kind of
On 23/12/2009, at 6:20 AM, glenn andreas wrote:
But when the kind of situation that calls for it arises, it might seem very
natural and elegant. I'm just suggesting that we not condemn an architecture
out of hand merely because we've no experience of it. m.
And isn't even that uncommon -
On Tue, Dec 22, 2009 at 5:22 PM, Graham Cox graham@bigpond.com wrote:
This is exactly the sort of code smell we were always on the look out for at
code reviews, and it was always avoidable. In every case, the revised code
was more elegant, maintainable and straightforward. I don't believe
On Tue, Dec 22, 2009 at 9:28 PM, Kyle Sluder kyle.slu...@gmail.com wrote:
See -[NSControl tag] for an example of where it's done in Cocoa.
Didn't finish my sentence. Specifically it is done with the tag by
-[NSTextView performFindPanelAction:]. It's not quite using the
caller's selector, but it
On Sun, 20 Dec 2009 15:39:08 -0800, Dave Carrigan d...@rudedog.org said:
On Dec 20, 2009, at 3:29 PM, Graham Cox wrote:
I think what the OP was talking about was making a called method sensitive to
its caller, which is a no-no.
That's what I thought the OP was saying, and I agree. It would
On 22/12/2009, at 4:48 AM, Matt Neuburg wrote:
That's what I thought the OP was saying, and I agree. It would mean that
doing
a refactor and changing a method's name, or even adding a new parameter to a
method, would break the code in some unrelated method. That's a huge
maintenance
i have a bunch of methods that will call one method. currently, i'm
passing a string object so the called method will know which method
had called it, and complete the proper task based on the method that
called it.
instead of creating strings and passing them, is it possible to pass
the method
On 21/12/2009, at 12:18 AM, Chunk 1978 wrote:
i have a bunch of methods that will call one method. currently, i'm
passing a string object so the called method will know which method
had called it, and complete the proper task based on the method that
called it.
Good programming practice
On Sun, 20 Dec 2009 08:18:36 -0500, Chunk 1978 chunk1...@gmail.com said:
i have a bunch of methods that will call one method. currently, i'm
passing a string object so the called method will know which method
had called it, and complete the proper task based on the method that
called it.
instead
You can pass the hidden parameter _cmd which is of type SEL you can then use
@selector(selector_name) to do your test, this whole thing you are doing
sounds really strange, it would be good to see what you are doing to find a
better approach. based on what little information your are giving us
On Sun, 2009/12/20, Graham Cox graham@bigpond.com wrote:
From: Graham Cox graham@bigpond.com
Subject: Re: passing a method name?
To: Chunk 1978 chunk1...@gmail.com
Cc: cocoa-dev Dev cocoa-dev@lists.apple.com
Date: Sunday, 2009 December 20, 07:29
On 2009/12/21, at 00:18, Chunk 1978
On Mon, 21 Dec 2009 00:29:00 +1100, Graham Cox graham@bigpond.com
said:
On 21/12/2009, at 12:18 AM, Chunk 1978 wrote:
i have a bunch of methods that will call one method. currently, i'm
passing a string object so the called method will know which method
had called it, and complete the
On Dec 20, 2009, at 1:05 PM, Jeffrey Oleander wrote:
On Sun, 2009/12/20, Graham Cox graham@bigpond.com wrote:
[...]
Good programming practice encourages the idea that
functions and methods are complete in and of themselves, and
are invariant under different calling conditions.
On 21/12/2009, at 5:05 AM, Jeffrey Oleander wrote:
OTOH
[]
An action is the message a control sends to the target
Target/action is not what I was talking about at all. It's OK to store a SEL
which is invoked as a response - the signature of that SEL does not change the
behaviour or state
On Dec 20, 2009, at 3:29 PM, Graham Cox wrote:
I think what the OP was talking about was making a called method sensitive to
its caller, which is a no-no.
That's what I thought the OP was saying, and I agree. It would mean that doing
a refactor and changing a method's name, or even adding
16 matches
Mail list logo
