Foundation/CPException.j: _CPRaiseRangeException and _CPRaiseInvalidArgumentException called METHOD_CALL_STRING(), undefined anywhere.
Every out-of-bounds CPArray access threw an
uncatchable JS ReferenceError instead of CPRangeException/
CPInvalidArgumentException.
Fixed to call the existing _CPMethodCallString(anObject, aSelector).
Tests/Foundation/CPArrayTest.j, CPMutableArrayTest.j: the defect
was invisible because test_objectAtIndex_ and test_objectsAtIndexes_
checked only that something was thrown, not what.
Added exception-identity checks, and fixed ConcreteArray/ConcreteMutableArray's
objectAtIndex: overrides, which threw a plain string and would have
failed the new checks.
As we have a tool-free bridges between many classes and JavaScript types by setting the isa property on the type, for example CPArray and Array. Using the for...in enumeration the isa property will be included in the loop if the property is enumerable (this is the default behavior). This commit set the property as not enumerable.
Also added test case for check that the isa property on classes are not enumerable using a for...in loop.
Without this fix, certain JS contents could cause `- CPDictionary description` and `- CPArray description` to crash.
This change limits how deeply the description code will recurse before returning a default "…" description.
Array literals look like `@[a, b, c]`.
This syntax is supported for completeness and source compatibility, but are not terribly useful since standard JavaScript arrays are toll-free bridged to CPArray.
Array literals could be handy if you're replacing CPArray with your own implementation.
---
Dont you hate when your logs of arrays and dictionaries display [Object object] when you have JavaScript objects in them. Now with this patch all JavaScript objects will be display with all attributes in a nice good looking way. Log CGRect, CGPoint and other JavaScript objects withour any hassle anymore. For example: console.log([myRect]);