Re: [Perl-widget-developer] Structure of Widget Base classes

[Stephen A. <ste...@of...>]

Hi,

Several people have commented on this topic.

Is it 1. Widget::HTML::Select ?
...or 2. Widget::Select::HTML ?

I believe that "all of the HTML widgets" have more in common
than "all of the Select widgets".  That's why I chose #1 rather
than #2.

Remember that a package structure is a logical grouping
which says *nothing* about the inheritance structure.
It has more to do with code organization, distribution, and
dependencies.  I would much rather delegate the entire package
of Widget::Curses to someone who is really good with Curses,
and delegate Widget::Gtk to someone who is really good with Gtk.
Each one of them could develop their packages and release them
independently on CPAN.

I really think there will be very little code in common between
"Widget::HTML::Button" and "Widget::WML::Button".
In fact, there is no reason to expect that every user interface
technology will even *have* a Widget::*::Button.
On the other hand, I can imagine that there might be a bit of
shared logic in whatever Widget::*::TreeView widgets exist.

The current inheritance tree is as follows.

   Widget::Base
     |
     +-- Widget::HTML::Base
           |
           +-- Widget::HTML::Select

#1. For these reasons, I recommend that the package structure *not* be 
    changed.

#2. However, if there exist multiple Widget::*::Select widgets which
    really should share code, then create a 

   Widget::Base::Select

which inherits from nothing, implements the logic which is common
to all Widget::*::Select classes, and use multiple inheritance to
let Widget::HTML::Select inherit from both Widget::HTML::Base and
Widget::Base::Select.

------------------------------------

This raises another issue.

How are we going to innovate when each innovation would create sweeping
changes to the code base, renaming packages, moving them in the package
structure, etc.?
(CVS does not take kindly to moving files around and then back.)

#3. I suggest that each of us who wants to revolutionize the code base
    (rather than evolve it), feel free to start with the Widget-0.02
    code base (or any recent snapshot from CVS) and revolutionize it
    on your own machine.  Ensure that the code still runs.
    (Making code actually work does a developer good.)  Then share
    what you learn with the list.  (Leave the CVS alone.)
    We'll see what happens from there.  We may decide we don't want
    the revolutionized code in CVS, or we may put you in charge of
    updating it in CVS. Just don't get your feelings hurt.

So even though I made recommendation #1, feel free to try it out on
your own under recommendation #3 and share with the list what you 
learned.

Until we get past this early period, we'd better not have each person
trying to update CVS independently.

Stephen

P.S. I think some of these issues will become clearer only when we
     get a much richer set of widgets in place.

>At 09:23 PM 6/5/2001 +1000, you wrote:
>>
>>I have a concern with the current structure of the base
>>classes.  Currently the way I see it, the structure is as follows
>>
>>Widget::Base - base class for all widgets
>>Widget::HTML::Base - base class for all HTML widgets (inherits Widget::Base)
>>Widget::HTML::Select - a widget class (inherits from Widget::HTML::Base)
>>
>>Now if we add WML we would get the following extra classes
>>
>>Widget::WML::Base - base class for all HTML widgets (inherits Widget::Base)
>>Widget::WML::Select - a widget class (inherits from Widget::HTML::Base)
>>
>>
>>My concern here is that there is no sharing of code between
>>Widget::HTML::Select and Widget::WML::Select besides the Widget::Base and
>>Widget::HTML::Base.  I think there should be a base class for Select
>>widgets that the HTML and WML Select widgets can inherit from.  Otherwise
>>we will be duplicating a tonne of code between the different interfaces.
>>
>>
>>Essentially, I think we have our Base class structure backwards.  What we
>>need to think about is what similarities and differences there will be
>>between the different interfaces.  The only method that should be
>>different in a Widget is the method that renders the actual widget.  
>>Everything else will most likely be the same.
>>
>>To fit a Widget::Select baseclass into the current structure would require
>>multiple inheritance, and I don't know if that is such a good idea.
>>
>>
>>What if we used the following structure:
>>
>>Widget::Base - base class for all widgets
>>Widget::Select - a generic dropdown box widget (inherits from Widget::Base)
>>
>>Widget::HTML::Base - a base class for HTML widgets (doesn't inherit)
>>Widget::HTML::Select - a display class for Select box 
>>				(inherits from Widget::HTML::Base)
>>
>>The Widget::Select object can instantiate the correct display object from
>>one of the interfaces once it knows (from the config file) which interface
>>we are displaying to. It can choose to use Widget::HTML::Select or
>>Widget::WML::Select depending on the requirements.
>>
>>
>>Does anyone have any other ideas or comments on the implications of this?  
>>I haven't thought this out completely yet, but I wanted to throw it out
>>before we got too deep into the coding.
>>
>>
>>-- 
>>Cees Hek
>>
>>
>>_______________________________________________
>>Perl-widget-developer mailing list
>>Per...@li...
>>http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
>>