rearrange was Re: [Perl-widget-developer] thoughts on design

[Gunther B. <gu...@ex...>]

At 05:53 PM 6/3/01 -0400, Stephen Adkins wrote:
>Cees,
>
>1. I am encouraged that someone is looking at the code.
>    Good for you Cees.
>2. Your suggestions are good, but your patches conflict with things
>    that I am working on.  I understand that it was worth it to you
>    just to play with the code.
>
>See below for comments.
>
>Stephen
>
>At 10:30 PM 6/2/2001 -0500, ce...@si... wrote:
>...
> >First off, any options we pass to a constructor should probably be in a
> >hash, so the user doesn't have to worry about order of variables:
> >
> >$anniv_dt = $wc->widget(-name => "anniv_dt");
> >instead of
> >$anniv_dt = $wc->widget("anniv_dt");
> >
>
>Good idea, but I don't like being forced to use named parameters for
>everything when a single parameter (i.e. $name) is what is almost always
>expected.
>
>Per Gunther, I considered CGI::Util::rearrange(), and opted for the
>rule: "when first char of first arg is dash (-), use named args".
>We may go to rearrange(), but it seems like a lot of overhead that we
>don't need. (CGI.pm had a huge installed base using an old syntax to
>support.)

Just a bit of history. The BioPerl initiative also had a similar discussion 
of what to do about named parameters. In the end, they ended up using a 
CGI.pm style with a slightly differently written rearrange method. Of 
course it is no coincidence that Lincoln Stein was part of BioPerl (loosely).

As I recall, the biggest deal is that you really need to stick with the 
convention of the preceding - for named params. The reason for this is to 
make it convenient not to have to quote them. When you allow for just 
simple names, then it's possible for those names to conflict with existing 
subroutine names. Before accepting them as a strings, Perl attempts to 
resolve unquoted values as constants (which are really subroutines).

I have to ask... what is the meaning behind your statement "rearrange is a 
lot of overhead to go with"...

Does that mean you are doing what rearrange does but in-line within the 
constructor?

It's also possible that you might want to use rearrange just for the 
constructor. It may be theoretically slower but you get stronger typing, 
and in a mod_perl universe where you may have many widgets, the overhead 
should theoretically only occur when the widgets are constructed. 
Hopefully, a mod_perl programmer would cache the widget controllers for 
subsequent requests.


> >In the first release, the Widgets were conpletely driven by hte Config
> >object.  I have added some support that allows the widgets to be
> >configured at initialization time as well as from the Config object.
> >This allows someone to create a Widget as such:
> >
> >    $widget = $wc->widget(
> >        -name       => 'category',
> >        -class      => 'Widget::HTML::Select',
> >        -values     => ['Foo', 'Bar'],
> >    );
>
>I knew people would want to do this, and I have been working on adding
>it myself.  However, I consider this usage the "low road".  It encourages
>people to do exactly what the library is supposed to get them away from ...
>caring about the details of the widget.  It also inhibits the configurer
>from snapping a new implementation of a widget in to upgrade the page.
>
>However, this is "simpler" and I expect that we will have "high road"
>users (using the library more ideally) and "low road" users (employing
>short cuts which somewhat short-change the real value of the library).
>
>Actually this philosophy is in keeping with Perl. ;-)
>There's more than one way to do it.

I don't understand precisely how you think the above code lends itself to 
not being configurable? As long as the parameters are a simple list, then 
in the main config of a CGI script, I can say

@CATEGORY_WIDGET = (-name => 'category' etc...);

And then within the code....

$widget = new Widget(@CATEGORY_WIDGET)

type of thing. Or within a custom controller.


>I have added you as a developer (CVS write access).
>However, please do not assume your changes will not conflict without
>discussing it first on the mailing list.
>And do not commit anything without first getting an OK on the mailing list.

Well small bug fixes are easily but the code seems so small right now that 
any major change will cause a CVS conflict upon merge. So this seems 
reasonable for now.

Later,
    Gunther