I'm not clear exactly how it would work without seeing the internals. 
Sounds cool conceptually, though.  Always nice to be able to pick and
choose what you want to use.

"  ZigoEngine.extend(PennerEasing, Shortcuts, Flash8Color, Flash8Filters);"

I wouldn't use extend as a method name, though!

Jim Kremens



On 10/22/05, Moses Gunesch <[EMAIL PROTECTED]> wrote:
> This post  goes out to really <anyone> here who's publishing and
> dealing with the f8 upgrades, not just the Fuse userbase. (Some
> exciting news guys, I've been confirmed to speak on Fuse at Flash
> Forward Seattle - hope to meet some of you folks there!) So while I'm
> awaiting Aral's resonse on whether Fuse will become an OSFlash
> project here's the lowdown.
>
> I'm strategizing on how I add solid f8 support into the kit without
> getting into a multiple version situation with my code, and without
> ditching on F7 users. I know many designers will tend to lag behind
> about a year in upgrading to the F8 authoring tool. Fuse is - for us
> - a complete syntax for condensing those pesky, but often necessary
> chunks of procedural code we all have to write, into something much
> tidier, more readable and OO. But still the base ZigoEngine (tweening
> engine) class is for everyone, and is favored by tons of beginning
> coders, so I do need to cater to both camps, including non-upgraders.
>
> So here's my idea: Architect one highly extensible package and give
> developers the option on what "extensions" to import. It would look
> like this (doesn't work with current version!) --
>     import com.mosesSupposes.fuse.*;
>     ZigoEngine.extend(PennerEasing, Shortcuts, Flash8Color,
> Flash8Filters);
>
> This way, just about everything becomes optional, which lets you
> control filesize more accurately. Like if you only plan to use 3
> easing equations you could just keep those separate and not use extend
> (PennerEasing), or if you never use the shortcuts (obj.alphaTo, etc.)
> you could omit extend(Shortcuts), plus select between F7Color vs.
> F8Color and so on.
>
> It also makes it easier for you guys, the OS community, to jump in
> and write your own additions to the kit which can be tossed in as
> separate "extension" classes, without having to muck around in the
> engine class itself.
>
> So what do you think about that strategy? Is this "overcomplicating"
> things (which I definitely want to avoid) - or keeping things as
> simple and flexible as possible?
>
> Thanks for your feedback!
> Moses
>
>
>
> _______________________________________________
> osflash mailing list
> [email protected]
> http://osflash.org/mailman/listinfo/osflash_osflash.org
>

_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org

Reply via email to