On Nov 30, 2006, at 5:35 AM, Tom Benson wrote: > Subclasses can provide much more functionality than a class extension. > > If your design requires the control to have extra properties or > events, then a subclass is a must. > > If you are only adding extra methods to a framework object (e.g. > adding another method to the listbox) then use an extends method
> (I have a whole Extension Library Module which extends the built in > framework to suit my needs), it's much cleaner and doesn't require > you to subclass all of your controls. Concerning extensions, I submitted an FR some time back to allow us to group all extension methods for a particular type or class and deal with them as one entity. Rather than have lots of extends functions all over the place, give RB the ability for us to create a special "extension" module where one specifies just ONCE - which type/class is being extended and then just add function definitions within the module without having to add the "extends" keyword etc to every function individually. To go along with this idea there ought to be be some kind of syntax in code ( "using" etc ) to allow classes to be instantiated that only adopt the extensions from the modules mentioned - For example: dim c as myClass extendwith myClassExtensionModule1, myClassExtensionModule1 Of course for the above to work there would have to be an "optional" flag for these new kinds of extension modules, in order to be able to specify which modules AUTOMATICALLY extend EVERY class/type of the module or whether the extension has to be specifically added in code. _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
