[Golist] the possibilities of go

Jon Williams jon at shovemedia.com
Wed Mar 5 09:03:48 PST 2008


it's not that i don't understand (or use) subclassing;
AS2 has strong-typing and subclassing etc too let's not forget.
i was just thinking about it from a newbie POV.

that said, i am *quite* an AS3 noob and haven't yet worked
on anything sufficiently complex that strong-typing has had the
opportunity to save my hide.

if the 'extra' prop is such a rotten approach, then i suggest
removing it from GoEvent (unless you can tell me how that's
different) ; ) Afterall, you should just subclass GoEvent...
:j


Moses Gunesch wrote:
> John, that's not a good idea, sorry.  :)
>
> That defeats all the benefits that as3 offers, you're still thinking  
> like an AS2 coder. The object that you add there would not be strictly  
> typed and so you are once again back in the dark ages of having to  
> hunt and peck for hours to track down mystery bugs. That's what strict  
> typing is for really, is to tighten up the ship so you can much more  
> specifically determine where and when bugs occur.
>
> There is no reason to fear subclassing. It's extremely simple, you  
> just need to know a little bit how it works. When you create a  
> subclass you inherit all the public and protected methods of the  
> superclass(es). You also have access to call the immediate parent  
> superclass' functions using the keyword super, like super.start().  
> This is handy because you can choose where in your overridden method  
> to call the super's method.. sometimes you need it to be before some  
> of your code, other times after, still others you might simply replace  
> the method's functionality entirely by not ever calling the super's  
> method. The only thing that is restrictive about AS3 is that  
> overridden methods have to "match" the super methods as far as input  
> datatypes and return datatype, and can't add or remove parameters...  
> personally I don't like this at all and it's making it hard to build  
> an open platform! (For example, you can't add a named parameter to  
> your subclass' start method without actually  modifying the base  
> class... this is terribly restrictive.)
>
> But in general, I'd say watch the LinearGo tutorial until you  
> understand what I'm doing with it, it's really not that difficult and,  
> since you're a professional who codes you really should take the time  
> to know how to do OO. I'm here for you if you have questions along the  
> way.
>
> - m
>
> PS I created an example called BlockTweenMG that lets you assign and  
> tween multiple properties very easily.. it's the same as the  
> MotionTween example but it uses a couple of arrays to store props &  
> endvals, then loops through the arrays to store tween start &  
> changevals in a few more arrays. So, this sort of structural  
> difference is significant and LinearGo leaves that open for subclasses  
> so it is not too restricting. Give it a try!
>
>
>
> On Mar 5, 2008, at 9:46 AM, Jon Williams wrote:
>
>   
>> i think the only thing i'd change is adding a public extra:* prop on
>> LinearGo
>> (same as there is on GoEvent). Though i'm not sure if that slows  
>> things
>> down due to
>> less-specific strong-typing...
>>
>> for my purposes, that simplifies the whole setup immensely because
>> i don't even have to subclass anything (and you KNOW people find
>> subclasses pretty daunting):
>>
>> create a linearGo, add the listeners, start it up,
>> inside the update event, i can get my object(s) and property(s) from  
>> the
>> extra obj above and pull the position via GoEvent.target.position.
>> from there convert from a percent to actual
>> coordinates or whatever right inside the event listener.
>>
>> done!
>>
>> :j
>>     
>
>
> _______________________________________________
> GoList mailing list
> GoList at goasap.org
> http://goasap.org/mailman/listinfo/golist_goasap.org
>   




More information about the GoList mailing list