On Thu, Jul 12, 2012, at 02:49 PM, Jens Alfke wrote:
>
> On Jul 12, 2012, at 2:44 PM, Kyle Sluder wrote:
>
> > Not necessarily. Now that we have blocks-as-IMPs
>
> *scratching-record sound*
>
> We do?! How do I get in on that goodness?
Use imp_implementationWithBlock (available as of OS X 10.
On Jul 12, 2012, at 2:44 PM, Kyle Sluder wrote:
> Not necessarily. Now that we have blocks-as-IMPs
*scratching-record sound*
We do?! How do I get in on that goodness?
—Jens
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post
On Thu, Jul 12, 2012, at 02:40 PM, Jens Alfke wrote:
> By comparison, creating the methods at runtime is comparably slow on the
> first call, then much faster after that. It's still going to be slower
> than a regular method call because the implementation has to figure out
> which method you were
On Jul 12, 2012, at 2:32 AM, Motti Shneor wrote:
> I already have dealt with forwardInvocation, in another class (some kind of
> NSNotificationCenter replacement which dispatches messages to registered
> objects, in prioritized and synchronized way). I think I can do it without
> much hassle.
Sent from Jane
On 2012-07-12, at 7:05 AM, Keary Suska wrote:
> The forwardInvocation implementation would be easy.
It would also be slow.
> In theory, all you need to distinguish is the setX vs X pattern, determine
> the actual key name (really just extracting and formatting when you get a
On Jul 12, 2012, at 3:32 AM, Motti Shneor wrote:
> Thanks Quincey. I seem to have missed that one.
Yes, Quincy is right. I was forgetting about the dot syntax issue as I haven't
been using it much for my implementation. Note, however, that if you plan to
use bindings with these objects you will
Thanks Quincey. I seem to have missed that one.
I already have dealt with forwardInvocation, in another class (some kind of
NSNotificationCenter replacement which dispatches messages to registered
objects, in prioritized and synchronized way). I think I can do it without much
hassle. This cover
On Jul 12, 2012, at 00:14 , Motti Shneor wrote:
> On 12 ביול 2012, at 02:54, Keary Suska wrote:
>
>> On Jul 11, 2012, at 2:45 PM, Motti Shneor wrote:
>>> Of what I read from everyone, and after examining the suggested code from
>>> Jens Alfke, I think I'm inclined to something simpler, hinted by
Thanks again Keary.
On 12 ביול 2012, at 02:54, Keary Suska wrote:
> On Jul 11, 2012, at 2:45 PM, Motti Shneor wrote:
>> Of what I read from everyone, and after examining the suggested code from
>> Jens Alfke, I think I'm inclined to something simpler, hinted by Keary
>> Suska. Could you spar
On Jul 11, 2012, at 6:53 PM, Dave DeLong wrote:
>
> On Jul 11, 2012, at 4:54 PM, Keary Suska wrote:
>
>> On Jul 11, 2012, at 2:45 PM, Motti Shneor wrote:
>>> Of what I read from everyone, and after examining the suggested code from
>>> Jens Alfke, I think I'm inclined to something simpler, hint
On Jul 11, 2012, at 4:54 PM, Keary Suska wrote:
> On Jul 11, 2012, at 2:45 PM, Motti Shneor wrote:
>> Of what I read from everyone, and after examining the suggested code from
>> Jens Alfke, I think I'm inclined to something simpler, hinted by Keary
>> Suska. Could you spare a few more words
On Jul 11, 2012, at 2:45 PM, Motti Shneor wrote:
> Of what I read from everyone, and after examining the suggested code from
> Jens Alfke, I think I'm inclined to something simpler, hinted by Keary
> Suska. Could you spare a few more words on the "undefinedKey" override?
I would create a base
On Jul 11, 2012, at 1:45 PM, Motti Shneor wrote:
> I'd like to avoid dynamic auto-generation of methods at runtime. I can't see
> why this is needed --- ALL my getters and setters will look exactly the same.
It isn't strictly _needed_, but it's the only alternative to creating all the
methods
On Jul 11, 2012, at 1:45 PM, Motti Shneor wrote:
> Wow, and thanks, everyone. BTW, what does "OP" stand for? (obviously, its
> me...)
OP = original poster
> Of what I read from everyone, and after examining the suggested code from
> Jens Alfke, I think I'm inclined to something simpler, hinte
OP = original poster (i.e the person who started the thread)
On Jul 11, 2012, at 4:45 PM, Motti Shneor wrote:
> Wow, and thanks, everyone. BTW, what does "OP" stand for? (obviously, its
> me...)
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Wow, and thanks, everyone. BTW, what does "OP" stand for? (obviously, its me...)
Of what I read from everyone, and after examining the suggested code from Jens
Alfke, I think I'm inclined to something simpler, hinted by Keary Suska.
Could you spare a few more words on the "undefinedKey" overri
On Jul 11, 2012, at 7:03 AM, Dave DeLong wrote:
> You'll have to override +resolveInstanceMethod: to figure out what the user
> is trying to do: get or set. You'll use the selector passed in to derive the
> key under which you're storing the data in the dictionary. With this
> information, yo
On Jul 11, 2012, at 8:03 AM, Dave DeLong wrote:
> It sounds like the OP is looking for a model object that uses an
> NSMutableDictionary as the backing store for its properties, as opposed to
> individual ivars. You can do this.
>
> You declare all your properties, and you declare a single NSM
On 2012-07-11, at 10:03 AM, Dave DeLong wrote:
> It sounds like the OP is looking for a model object that uses an
> NSMutableDictionary as the backing store for its properties, as opposed to
> individual ivars. You can do this.
>
> You declare all your properties, and you declare a single NS
It sounds like the OP is looking for a model object that uses an
NSMutableDictionary as the backing store for its properties, as opposed to
individual ivars. You can do this.
You declare all your properties, and you declare a single NSMutableDictionary
ivar. All of the properties should be imp
On Jul 11, 2012, at 6:34 AM, Motti Shneor wrote:
> Hi. I guess many have already stumped into this one, but my wildest phrasing
> attempts in web-searches didn't yield.
>
> I'd like to have a "data" object, similar to (but much simpler than) CoreData
> entity, which only exports a bunch of pro
21 matches
Mail list logo
