On Nov 30, 2006, at 2:00 PM, Daniel Stenning wrote:
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.
Why?
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.
Flags signal complication.
Charles Yeomans
_______________________________________________
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>
