* [Optimization] Convert to type-generic math
* add std:: prefix in obj-c++ files
* more cleanup
* revert test changes
* convert min and max back to fmin/fmax
[ASRangeController] We're already on main thread, remove blocks
Make data source read-only, clarify what's asynchronous
[ASDataController] Clean up some interfaces
[ASDataController] A little more cleanup
[ASDataController] Cleanup
[ASDataController] Restore some changes, exit more often
[ASDataController] Use item counts that we already have rather than requerying them
[ASDataController] Revert weakifications
[ASDataController] Add a mechanism to measure how much work we avoided
The pending layout transition needs to stay alive at least until applySubnodeInsertions did finish execute as it can happen that with Implicit Hierarchy Management new nodes gonna be added that internally call setNeedsLayout what will invalidate and deallocate the transition in the middle of inserting nodes
Using Objective-C attributes, in this case `unavailable`, we can hide
unsupported APIs at compile time instead of detecting and warn about it
at runtime with a set of asserts.
* Because Pods and the Podfile.lock are not checked in, they should be removed before installing. Otherwise the state is not consistant.
* Pod install no longer updates the repo
* Copy changes to split up examples.
* Revert "Revert "[ASLayoutSpec] Use childrenMap directly to prevent creating an NSArray within ASDK (#1937)""
This reverts commit 735b4ebd08.
* Fix crash and add exception for mutating while using fast enumeration of ASLayoutSpec children
NSFastEnumeration is potentially quite dangerous in the wrong hands. In particular, it does not provide a safe mechanism for you to return temporary objects directly, and it does not provide any guarantee that you will be called when the enumeration has completed; therefore if we generate temporaries and store them in an instance variable, we will not necessarily be able to clean them up! This means fast enumeration methods should never be called within an autorelease pool or the autorelease pool be drained within the fast enumeration loop.
The reason is we store references to objects in the stackBuf struct by casting the child pointer to __autoreleasing id. If we pop the autorelease pool between calls to -countByEnumeratingWithState:objects:count:, it will die in a messy explosion of pointer dereferences and EXC_BAD_ACCESS.
* Add tests for ASDisplayNode and ASLayoutSpec fast enumeration
If a node was added to a supernode, the supernode could be in a layout pending state. All of the hierarchy state properties related to the transition need to be copied over as well as propagated down the subtree. This is especially important as with Implicit Hierarchy Management adding subnodes can happen while a transition is in fly
This triggers on existing code that needs to be updated, but also there is some investigation
needed as to whether it is a valid use case to have a >1.0 value in order to position greater-than-bounds elements.
