|
Re: Data structures and user interaction conundrum
Graham,
I am picturing a radix trie with n-bit keys where n is 32 or 64—whichever suits your z-orders. Keys represent the z order. Each object is a leaf in the trie. In each object, store its
Graham,
I am picturing a radix trie with n-bit keys where n is 32 or 64—whichever suits your z-orders. Keys represent the z order. Each object is a leaf in the trie. In each object, store its
|
By
David Young
·
#1276
·
|
|
Re: Data structures and user interaction conundrum
Are the zObjects integers? If so would it help to make them floats? Intial value 3.0; Back one 2.9 or 2.09; Forward one 3.1 or 3.01?
Or have I not understood your architecture or the memory
Are the zObjects integers? If so would it help to make them floats? Intial value 3.0; Back one 2.9 or 2.09; Forward one 3.1 or 3.01?
Or have I not understood your architecture or the memory
|
By
Peter Teeson
·
#1275
·
|
|
Data structures and user interaction conundrum
Hi all,
I Have an interesting little problem, thought I’d throw it out there and see if it stirs up any discussion….
Graphics app, wherein the user can draw stuff - arbitrary vectors on a canvas.
Hi all,
I Have an interesting little problem, thought I’d throw it out there and see if it stirs up any discussion….
Graphics app, wherein the user can draw stuff - arbitrary vectors on a canvas.
|
By
Graham Cox
·
#1274
·
|
|
Re: Abstracting a group of commonly named Selectors
I learned a lot from this thread - thanks!
I learned a lot from this thread - thanks!
|
By
robmartin@frontiernet.net
·
#1273
·
|
|
Re: Abstracting a group of commonly named Selectors
Jeff,
Switch languages!!! Noooo…
Jeff,
Switch languages!!! Noooo…
|
By
Sandor Szatmari
·
#1272
·
|
|
Re: Abstracting a group of commonly named Selectors
Jeff,
Couldn’t agree more…There is no need to optimize for performance here… higher level Obj-c interfaces are preferable.
Yes, lots of efficiencies can be made. Unfortunately, it’s just not
Jeff,
Couldn’t agree more…There is no need to optimize for performance here… higher level Obj-c interfaces are preferable.
Yes, lots of efficiencies can be made. Unfortunately, it’s just not
|
By
Sandor Szatmari
·
#1271
·
|
|
Re: Abstracting a group of commonly named Selectors
On review, one thing. Don't do this:if ( [self respondsToSelector:sel] == NO )
It's a boolean method, never use an equality check for "true" or "false" on a boolean method, even if it seems to work,
On review, one thing. Don't do this:if ( [self respondsToSelector:sel] == NO )
It's a boolean method, never use an equality check for "true" or "false" on a boolean method, even if it seems to work,
|
By
Jeff Laing
·
#1270
·
|
|
Re: Abstracting a group of commonly named Selectors
This capability of Objective-C, to create classes on the fly, is one of the primo reasons why I can't understand people's fascination with Swift. Even C# can do this sort of thing, but people these
This capability of Objective-C, to create classes on the fly, is one of the primo reasons why I can't understand people's fascination with Swift. Even C# can do this sort of thing, but people these
|
By
Jeff Laing
·
#1269
·
|
|
Re: Abstracting a group of commonly named Selectors
Jeff,
Works great! See my implementation below…
The one thing I wasn’t sure about was the types array argument for class_addMethod() The fourth param…
I used ‘i’ to specify the return type
Jeff,
Works great! See my implementation below…
The one thing I wasn’t sure about was the types array argument for class_addMethod() The fourth param…
I used ‘i’ to specify the return type
|
By
Sandor Szatmari
·
#1268
·
|
|
Re: Abstracting a group of commonly named Selectors
Jeff,
So what you’re suggesting is…
1. Define a template implementation
2. Associate each selector pattern with that implementation
That seems like it should work. I’ll give it a try and let
Jeff,
So what you’re suggesting is…
1. Define a template implementation
2. Associate each selector pattern with that implementation
That seems like it should work. I’ll give it a try and let
|
By
Sandor Szatmari
·
#1267
·
|
|
Re: Abstracting a group of commonly named Selectors
In the designated initialise of your Parser class, you can use class_addMethod to add whatever you like to your instance's
In the designated initialise of your Parser class, you can use class_addMethod to add whatever you like to your instance's
|
By
Jeff Laing
·
#1266
·
|
|
Re: Abstracting a group of commonly named Selectors
Jeff,
Thanks for the idea… it might be a good choice… as for additional details.
The caller can be seen as a controller. It dynamically allocates model (parser) classes based on context.
The
Jeff,
Thanks for the idea… it might be a good choice… as for additional details.
The caller can be seen as a controller. It dynamically allocates model (parser) classes based on context.
The
|
By
Sandor Szatmari
·
#1265
·
|
|
Re: Abstracting a group of commonly named Selectors
You really haven't provided enough information about the caller, and you've skipped over the C programmers favourite answer.Presumably you actually NEED all those seperate selectors and can't just
You really haven't provided enough information about the caller, and you've skipped over the C programmers favourite answer.Presumably you actually NEED all those seperate selectors and can't just
|
By
Jeff Laing
·
#1264
·
|
|
Re: Abstracting a group of commonly named Selectors
Gary,
interesting…
I’ll have to see if Returning an NSValue wrapped scalar translates to the scalar result on the other side when I call -getReturnValue:
Thanks!
Sandor
Gary,
interesting…
I’ll have to see if Returning an NSValue wrapped scalar translates to the scalar result on the other side when I call -getReturnValue:
Thanks!
Sandor
|
By
Sandor Szatmari
·
#1263
·
|
|
Re: Abstracting a group of commonly named Selectors
Alex,
I am proposing letting the runtime handle the fact the object does not respond to the selector. So, under this assumption I am inside one of two methods:
-doesNotRespondToSelector: or
Alex,
I am proposing letting the runtime handle the fact the object does not respond to the selector. So, under this assumption I am inside one of two methods:
-doesNotRespondToSelector: or
|
By
Sandor Szatmari
·
#1262
·
|
|
Re: Abstracting a group of commonly named Selectors
You might want to consider using valueForUndefinedKey: and parse it to know which value you care about, and then return the value through NSValue, which can encapsulate any value, although a
You might want to consider using valueForUndefinedKey: and parse it to know which value you care about, and then return the value through NSValue, which can encapsulate any value, although a
|
By
Gary L. Wade
·
#1261
·
|
|
Re: Abstracting a group of commonly named Selectors
Well, I’m guessing here, but can’t you construct the method and use a perform selector, get the result and return it?
It seems like you are making methods, performing them, then need to perform
Well, I’m guessing here, but can’t you construct the method and use a perform selector, get the result and return it?
It seems like you are making methods, performing them, then need to perform
|
By
Alex Zavatone
·
#1260
·
|
|
Re: Abstracting a group of commonly named Selectors
Alex,
Thanks for the idea. I not sure how that helps me get the return value back to the original caller. Am I missing your point?
Here’s more details, in pseudo code
// Controller class
SEL
Alex,
Thanks for the idea. I not sure how that helps me get the return value back to the original caller. Am I missing your point?
Here’s more details, in pseudo code
// Controller class
SEL
|
By
Sandor Szatmari
·
#1259
·
|
|
Re: Abstracting a group of commonly named Selectors
Would it be possible to put them in an array or dictionary as NSStrings and use performSelector on one of them if it is present within the array or dict?
Would it be possible to put them in an array or dictionary as NSStrings and use performSelector on one of them if it is present within the array or dict?
|
By
Alex Zavatone
·
#1258
·
|
|
Abstracting a group of commonly named Selectors
I have a certain group of selectors that all follow a strict naming convention,
-(Status)parseXYZ
-(Status)parseRST
All have one line that does the same thing and return a scalar (enum) as a
I have a certain group of selectors that all follow a strict naming convention,
-(Status)parseXYZ
-(Status)parseRST
All have one line that does the same thing and return a scalar (enum) as a
|
By
Sandor Szatmari
·
#1257
·
|