refactor: reduce amount of work on initialization

[alexlafroscia]

• Simplify approach to wrapping most properties
• Reduce the amount of work done when initializing objects

---

This is a follow up to some of the feedback given in #85

[pzuraq]

One thing I'm realizing is that unless we call super, the last class that defines the argument will always win:

class Foo {
  @argument('string') baz;
}

class Bar extends Foo {
  @argument('number') baz;
}

We may need to store all of the validators in an array with addValidationFor and then run all of them in the setter.

[alexlafroscia]

I'm not sure I'm following -- Are the usage in Foo and Bar related, even though the classes are independent?

[pzuraq]

yes sorry, that was a typo, corrected

[alexlafroscia]

Gotcha. We'd talked about this briefly earlier -- we have a few options for defining arguments for the same property on multiple components in a hierarchy

1. First one (lowest in the chain) is run
2. Last one (highest in the chain) is run
3. All of them are run

We currently do the first option there, but I'm happy to refactor to run all of them. That should be pretty easy now with our and combinator!

[pzuraq]

I'm not sure we need to run validations here, since class fields and getters/setters will trigger when the values are set anyways. I suppose the init part of the error message is still somewhat valuable, but it probably won't show up anyways since the error for the accessor will trigger first.

[alexlafroscia]

That would remove the init validations altogether, right?

I'm fine with that, personally -- I think it probably makes more sense just to run the validations on get/set

[alexlafroscia]

So, I looked into this and I'm not sure that it'll make sense to remove the init validation.

I tried removing the validator on init and adding a validator to get. This had the side-effect of making it impossible to check that the props passed to the object match the expected validation, because as part of initializing the object in .create(), the initial value is accessed. Basically, the validation on get will be called before the property is overwritten with the new value, which doesn't work.

[pzuraq]

We should probably add some tests that cover inheritance behavior, to make sure that it works correctly.

[alexlafroscia]

The tests in tests/unit/argument-test.js should cover the inheritance use-case -- there are a number of examples there around extending classes with @argument defined in a base class and overwritten (or not) in a parent class.

[alexlafroscia]

^ Rebased to make compatible with the conflicting changes in #90

[alexlafroscia]

New ComputedProperty implementation in in 3.9 trolling our tests... I'll take a look at adding ember-compatibility-helpers to address that issue, but would appreciate a re-review with the feedback I've left on the various "conversations" still open here!