I feel like we should adopt some standard terminology for method names and objects. The terminology should be intuitive and also help the documentation and code be more consistent.
One issue is what to call the object being tweened. Sometimes I have referred to it as the "target" object, because it is the object targeted by the tween, although that could be confused with the object containing the final values. We can call starting values and ending values the "start value object" and "end value object", or "source object" and "destination object".
It is also important that we use good idioms when designing the es6 API. In the current version I think that users probably find the distinction between "remove()" and "stop()" confusing. It's made worse by the fact that we have no real "pause()" method. Also, if we did have a "pause()" method, then it would need to be clear which kind of pausing it did - there's the kind where it will jump ahead when it resumes, and the kind where it will continue where it stopped when it resumes.
I know this can seem trivial, but many users will not want to spend more than 5 or 10 minutes trying to understand this library, so we want to make things common-sense and easy to comprehend.
I feel like we should adopt some standard terminology for method names and objects. The terminology should be intuitive and also help the documentation and code be more consistent.
One issue is what to call the object being tweened. Sometimes I have referred to it as the "target" object, because it is the object targeted by the tween, although that could be confused with the object containing the final values. We can call starting values and ending values the "start value object" and "end value object", or "source object" and "destination object".
It is also important that we use good idioms when designing the es6 API. In the current version I think that users probably find the distinction between "remove()" and "stop()" confusing. It's made worse by the fact that we have no real "pause()" method. Also, if we did have a "pause()" method, then it would need to be clear which kind of pausing it did - there's the kind where it will jump ahead when it resumes, and the kind where it will continue where it stopped when it resumes.
I know this can seem trivial, but many users will not want to spend more than 5 or 10 minutes trying to understand this library, so we want to make things common-sense and easy to comprehend.