<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br class="webkit-block-placeholder"></div><div>Thanks for clarifying a bit Moses... I also think that a great way for some users to start diving into Go is to see it as a comparison to Fuse. I know a lot of designers and developers (including me) know Fuse inside and out after using it for so long. I think perhaps a great way to introduce Go to those veteran Fuse users is with a simple fla or tutorial showing what Go is in a Fuse context. A lot of the time I learn new techniques through dissection of a fla because things are already grouped in a familiar environment (e.g. this is a nav button, this is an animated mc, this is what happens after it animates, etc...). In this context we all know what each item is supposed to do and how we would code that using Fuse, but to show how that would be coded with Go would put things into perspective. I hope I didn't get too confusing there... I can clarify a bit if things don't make sense.</div><div><br class="webkit-block-placeholder"></div><div>Patrick.</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><br><div><div>On Mar 4, 2008, at 4:32 PM, Moses Gunesch wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Thanks for the thoughts Tim..</div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><font class="Apple-style-span" color="#000000"><br class="webkit-block-placeholder"></font></div><div>I think the perception of Go being complicated also comes from people's familiarity with Fuse. Fuse was easy to use, but went pretty deep by comparison, which could be throwing people. </div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>I think for projects, the drive is to find something that works and is already built because you need it immediately and don't have extra time to mess around thinking about the mechanics of it. Fuse was geared toward prepackaging everything in that way and hiding its complexity. So, yeah.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>The idea of building Fuse with Go sounds daunting, and there could be a sense that you are required to roll all that functionality yourself, even though it might not be required for the code you're writing. People hate losing options, even when it costs them.</div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>I can't wait to get time to show you guys this tutorial on how you can build a parser in just a few minutes. It is really, super easy. It doesn't have too many complex features in it, true, but I think as time goes on people will start building those out again.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">Also, it's possible that people are confused by the methodology change. Instead of controlling everything through the Fuse class, you create individual tween objects, which <i>seems</i> more complex.</span></div></div></blockquote><br></div><div>Actually that's a misconception right there – the Fuse style parser I wrote worked with static methods, where you never see any tween classes at all. So, yes the tween objects are exposed for OO-style extensibility, but that does not limit you to that style as your final end product at all. For example let's say you write a tween class like HydroTween.. simply add a static method HydroTween.go() that generates and starts a tween, and you have a totally clean usage. </div><div><br class="webkit-block-placeholder"></div><div>I like that it gives you both options – you can still make a new tween and store it in your code for reuse, which is far more efficient than generating one every time, or use the static call to avoid having to bother making the instance and then starting it. Even a third usage would be new CustomTween(...).start() which is pretty much the same as the static call would be, unless the static method does something special to it. </div><div><br class="webkit-block-placeholder"></div><div>Go not about offering "features" that you have to learn, like an API does. The options that it leaves open are just normal AS3 coding options that are always there... maybe people are just uncomfortable <i>not</i> being locked into one narrow way of doing things?</div><div><br class="webkit-block-placeholder"></div><div>- m</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div></div>_______________________________________________<br>GoList mailing list<br><a href="mailto:GoList@goasap.org">GoList@goasap.org</a><br>http://goasap.org/mailman/listinfo/golist_goasap.org<br></blockquote></div><br></body></html>