Previously, CPArray did not allow binding to the collection operator @count. In Cocoa this is allowed.
This commit allow the key path @count to be observed, so that @count can be bound to.
Formatting fixes as well.
Previously, Cappuccino was using preprocessor macros internally for the CGPoint/Size/Rect/Inset/Affine functions, as well as for CPRange. These macros had the same name as the corresponding function, but began with _. The functions were actually defined using the macros.
The motivation behind using macros was to increase performance by reducing function calls. However, there were a number of problems with this approach:
- There was an artificial dichotomy between _CG macros and the corresponding CG functions. We never completely replaced CG function calls with _CG macros. In fact, they were often mixed up in the same file. There was an extra burden on the programmer to remember to use the macro instead of the function.
- If a method call was passed as an argument to a macro, performance could actually be significantly *worse* than a function call. For example, _CGGetRectMakeCopy([view frame]) would expand to `{ origin:{ x:[view frame].origin.x, y:[view frame].origin.y }, size:{ width:[view frame].size.width, height:[view frame].size.height } }`. So instead of a single objj_msgSend and a single simple function call, we ended up with 4 objj_msgSend calls, which are way more expensive than simple function calls.
- Because of this expansion problem, to use macros efficiently required us to remember to use variables for all macro parameters. This didn't happen, and shouldn't have to happen.
- Finally, with modern Javascript engines, function call overhead is so small that it really isn't worth using the macros.
This commit eliminates the _CGGeometry, CGAffineTransformation and CPRange macros and replaces them with function calls.
BREAKING CHANGE:
The macros are no longer available. They could only be used with compiled code, but if there is any user code that used them, they will have to be replaced with the corresponding functions.
- CPView and subclasses support multiple-value hidden bindings.
- CPControl and subclasses support multiple-value enabled bindings.
- CPWindow and CPBox support multiple-value title with pattern bindings.
- CPButton supports multiple argument + target bindings.
- CPImageView and CPTextField support multiple-value editable bindings.
- CPMenuItem supports multiple-value enabled bindings.
- Fixed bugs in CPObjectController with simple collection operators.
- CPColorWell uses black as the placeholder color.
- Runtime object attributes from a cib are applied as they are read, not deferred.
- NSNumberFormatter now reads the number style from the xib.
- Normalized some parameter names.
- Formatting.
- Test app for all binding types.
mutableArrayValueForKey: … removeObjectsInArray should remove all instances of the found objects. Without this fix, only the first instance was removed.
Without this fix, KVCArray could try to remove an out of bounds index at CPNotFound from its target array.
This fix makes it so that only found objects are removed.
- Moved common CPArray/CPSet collection KVC operators to _CPCollectionKVCOperators.
- Implemented KVC operator dispatch using Objective-J.
- Fixed infinite loop with empty collection in @min, @max and @sum operators.
- Correctly return valueForUndefinedKey when necessary.
- valueForUndefinedKey reason uses raw description for consistency, class' overridden description may not helpful at all.
- Don't create a forwarder for @ operators with property paths.
- Fixed CPSet -valueForKeyPath to correctly deal with nil/undefined/empty values.
- Added tests for collection KVC operators.
- enumerator -nextObject should always compare against nil for clarity, correctness, and consistency.
Refactored everything away into insertObjects:atIndexes: so all the logic is in the same place
and made it so that the _insertManySEL is the preferred selector to use. If it doesn't exist it will fall back to the _insertSEL.
- valueForKeyPath: looped over individual components, which meant classes couldn't override valueForKeyPath: to do multi-part keys (needed for operators)
- CPArray's valueForKeyPath: implementation was incorrectly parsing the operator if it was a simple key
Martin CarlbergandGitHub
daniel
Aparajita Fishman
Alexander Ljungberg
Ilya Kulakov
Alexander Ljungberg
Klaas Pieter Annema
Daniel Stolzenberg
Ross Boucher
Stephen IerodiaconouandRoss Boucher
cacaodevandRoss Boucher
Francisco Ryan Tolmasky I
Tom Robinson