Hey Laurent,
it took me a couple of days to ask my friend if I could forward his
code which he agreed upon yesterday so here is a tar.bz2 containing
all the code. We ran the »test/minheap_performance_test.rb«. Note that
it contains lines (35, 43, 51) which use the large number of method
a
Yes, it could work that way too. In this scenario where you just need
to call #update, if the game controller keeps an array/set of child
items, you could just call
[gameItems makeObjectsPerformSelector:@selector(update)];
You would use KVO in the following hypothetical scenario, which is
adopte
#329: Invalid NIB file for RoundTransparentWindow example
+---
Reporter: ernest.prabha...@… | Owner: mattaimone...@…
Type: defect | Status: new
Pri
The project is a simple demo game using the same approach explained by Brian
where game items listen for notifications and update themselves based on the
notification.
For some reasons, I think it would be easier for the game controller to know
about the game items and call #update on each of them
#329: Invalid NIB file for RoundTransparentWindow example
+---
Reporter: ernest.prabha...@… | Owner: lsansone...@…
Type: defect | Status: new
Priorit
I am also not sure that I fully understand this scenario, but it
doesn't appear that you would need KVO. Do the "tasks" or the "Brain"
have any properties to observe?
As Ben points out, KVO really shines when you need to keep a UI in
sync with the state of a model.
If "tasks" just need to know wh
Coming from a Ruby background, I try to understand and pick the
best from Obj-C/Cococa and learn how to use brilliant ideas to
improve my coding.
Tonight I was working on a simple demo app to learn how things are
done in the Obj-C world and see how they would transpose to the
MacRuby wor
#328: Calling a ObjC-method with a named argument which is a Ruby keyword does
not work
+---
Reporter: d...@… | Owner: lsansone...@…
Type: defect | Status: new
Priority
