Because length is only ever expired as a consequence of a call to arrayContentDidChange, we need to make such a call at the end of init, because length could be calculated before childViews has been set up, and any properties or observers dependent on length will break until a subsequent mutation results in a call to arrayContentDidChange.
I talked to @kselden and he expressed concern about this solution. That said, I hope to get his explanation in here for you to see first hand. I don't want to close this without an explanation.
I would definitely appreciate one. I did go back and forth on whether, if the array isn't done initialized yet, if it really 'changed,' but considered that mere semantics.
i didn't merge this: https://github.com/emberjs/ember.js/commits/master EWUT github?
I don't think you could have if you wanted to.. I force pushed my fork back to standard ember a little while ago precisely because this stupid commit (on master instead of a branch, d'oh) was giving me merge difficulty. I forgot this PR was even still open.
crazy, ya I was merging unrelated PR's.. crazy. Anyways, I tweeted the issue to @github
Weird too that the in-line message gives a commit hash but at the top it says "stefanpenner merged 0 commits into emberjs:master from endash:master"