I disagree. Putting your changes in a derived class requires readers to look in two (or more) places to understand how the code works. That kind of complication is only justified when you need *actual* polymorphic behavior. Modifying the behavior of an existing class because it's incorrect (or unsatisfactory) is not a reason to introduce polymorphic behavior. If you had several *kinds *of jumping and you wanted the player to use one or another at different times, that would be a more reasonable use of inheritance.
Paul On Sun, Dec 20, 2009 at 1:15 AM, Christopher Harris <[email protected]>wrote: > Nice, only suggestion would be to have it propose to use a derived class to > make edits as it is generally cleaner that way to merge with new sdk > updates. Newer coders usually edit directly in existing classes and just > makes merging a big mess. > > Chris > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Jonathan > White > Sent: Tuesday, December 15, 2009 11:30 PM > To: [email protected] > Subject: Re: [hlcoders] why UnDuckJump? > > http://developer.valvesoftware.com/wiki/Duck_Jump_Fix > > Theres my fix for duck jumping (in terms of hitbox sync issues and stuff) > :-) > > Jonathan White > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
