[Golist] tween classes versus all-in-one

[Moses Gunesch]

On Apr 17, 2008, at 10:41 AM, Tollman Owens wrote:
> I can only see the benefit of doing all of the extra functionality in
> external classes for legibility, because you are going to
> get the weight when you do the import, so being able to save file size
> is not really an issue, please correct me is i am wrong.

It's not about legibility, it's about modularity.

Think about it from an Object-Oriented and Open-Source Sharing  
perspective: Whoever extends LinearGo with the best (simplest, most  
coherent, most functional) set of basic tween classes will be  
providing a bedrock foundation for everyone else.

The most attractive set of basic tween classes put out by one of you  
should end up receiving a VERY high adoption rate, because this set of  
basic tween classes can be repurposed for ANY parser or more complex  
system. No one has so far realized this and picked up the gauntlet  
but, I'm freely handing it to all of you for the taking. So go ahead,  
get famous if you want. ;-)

Such a set is not included in GoASAP in order to maintain purity:
Go is a base system that doesn't propose any specific syntax, not even  
for tween classes, because there are so many approaches to that  
interface.


A basic list of tweens might be something like this:
  * A DisplayObject tween
  * A generic any-object/ any-property multiple-value tween
  * A generic any-object/ any-property multiple-value tween
  * A ColorTransform tween (could subclass the multi-value tween)
  * A BitmapFilter tween
	(could be several of them since some filters are multi-value)
  * A Bezier-arc tween

Just my two cents.

moses