Closed joostverdoorn closed 10 years ago
:+1: for code, but for completeness, could you rebase master onto this branch first and resolve the conflicts? Im curious if everything will still play nice together
And I want to see the Travis CI coverage data (which is not actually from travis but you get the idea)
I don't see the use of rebasing master onto this branch. What sort of conflicts would you expect?
Mostly since git apparently cant automerge this branch with develop (Github cant merge the PR). Rebasing beforehand gives us the possibility to run the test suite again and get insight if everything progresses as we hope
Ah, you mean develop, you said master. Sure, I'll rebase this branch onto develop. It updated since I created the PR. Git has issues merging the compiled versions (tails.js and tails.min.js) sometimes, so I'll just recompile them.
Plus I generally prefer that a Pull Request shows exactly what will happen with the merge, that way we can detect an incorrect merge before it goes into develop
. In my opinion, a PR should be non-ambigious to what will happen when enough thumbs up are given
/edit: I mean develop
, not master. Excuse me for that mistake
:+1:
Dynamic properties haven't really proven useful, and they might make sense for model attributes. In this PR this change is also used in the relations mixin, where it simplifies the code.
Lazy properties could also be useful when we don't want to instantiate a property until it is needed. This might speed up loading times in some cases.