[Golist] tween classes versus all-in-one

[Moses Gunesch]

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

The alternative is an "all in one" approach (see my previous email for  
the OO approach).

In my opinion baking all tween functionalities into a single  
centralized class is not the way to go.

I have expressed that to Donovan before about HydroTween, but I like  
that different people can take their own directions with Go as well,  
and I really do dig what Donovan is doing on many levels. I mean, I  
took the all-in-one approach with Fuse myself, so it's really just my  
opinion this year. :-)

What I found with Fuse was that it became a veritable dreadlock of  
tangled code, where one thing going wrong in one place can break  
things unexpectedly elsewhere. Part of why I did that was AS2 and AVM1  
related, it was simply more efficient to tightly pack things. It also  
had to do with the general public at that time, which was still  
relatively scared of OO and liked to see the simplicity of just two  
classes called Fuse and FuseItem.

-

Anyway, having separate tween classes is a clean, OO approach that  
leverages the openness of Go's framework and extends that outward. So  
with a grain of salt (Go is a 100% open project and this is just my  
personal opinion), I encourage the modular approach.

Later, to avoid compilation of all classes, a registration system can  
exist at the parser level to link specific property key strings with  
tween classes dynamically. It is the parser that might accidentally  
need to import every single tween class to function but that would  
define a limited set as well as compile all of them. Registration can  
solve that issue by leaving things open.

So at the OO level, if you don't want to compile a tween you simply  
don't use it. At the parser level, you register the set of tweens you  
plan to need into memory so they get compiled and can be dynamically  
instantiated internally by the parser. Parser utilities float above  
tween functionality in my opinion. They are just syntactical "helpers"  
that compact OO code into a smaller, more intuitive, or more packaged  
format.

That's the simplest approach, but I also find it amazing that myriad  
other designs are possible within Go and am excited to see people  
experimenting. There's a great chance that one of you will stumble on  
a great architecture or solution that is totally unique, so don't feel  
like you have to follow one particular path! :-)

moses

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://goasap.org/pipermail/golist_goasap.org/attachments/20080417/fee78900/attachment.html