At 10:22 AM 5/24/2001 -0700, Paul Lindner wrote:
>On Thu, May 24, 2001 at 09:59:36AM -0400, Chip Turner wrote:
> > darren chamberlain <[EMAIL PROTECTED]> writes:
> >
> > The nice thing about closures is they could hide any interface at all
> > behind them; all that is required is that the function that generates
> > the closure follow the very simple convention of "return the formvar
> > of the name starting with the first parameter you're called with."
> > There is absolutely no reliance upon the underlying object structure.
> > What you're suggesting is equivalent to assuming the object is derived
> > from some kind of base class that supports the param() method though
> > without actually having to be ISA of that class. That's naughty OO
> > programming :) Just because perl lets you be typeless doesn't mean
> > it's always in the best interest of clean design to do so.
>
>I don't find a problem with passing an object that has a certain set
>of method signatures. This is functionally loosely equivalent to a
>Java Interface.. Any perl object can implement a particular interface
>just by implementing the methods.. No base class required..
>
>But I agree, closure are very cool, and allow for an additional layer
>of abstraction between the objects, without having to create a proxy
>class..
I think closures would only be cool for performance. I personally do not
think it is very intuitive. This is OK if the only things we consider
supporting as data sources for the widget are Apache::Request and CGI.pm.
However, I think it is reasonable to make the interface to support a data
source for the widgets flexible and object based to make it easy for
someone to write a DBI source, a DBM source, an LDAP source, an
Apache::Session source or whatever anyone wants really. I happen to think
DBI and Session sources are cool.
This also leads us to the idea of data handlers. We realized early on that
model-view-controller doesn't mean just templates because templates only
understand OUTPUT part of the view. The INPUT part of the view is just as
important and in many cases can be divorced from business logic for most
simple validations. This led us to do a data handler architecture (ie
http://www.extropia.com/development/webware2/chap12.pdf)
The idea of widgets ties very closely into this because just as widgets
require a data source to be populated, widgets themselves should have some
capability (through get and set methods) to act as a data source
themselves. Either to our data handler architecture or... and this is also
"cool", to other widgets.
It's entirely conceivable that you want the capability of other widgets on
the screen to have different defaults based on the values of other widgets.
The rules for "chaining" the data sources into a widget could be as simple
as that -- chaining.
By default, it could be GPC chaining like PHP (Get, Post, Cookie).... But
with enough widget data sources to choose from you could do
GPCSD (Get, Post, Cookie, Session, Database) type of thing.
This may sound like an overengineered design, but the reality is that most
casual developers will just use GPC like PHP does. It's when you get into
more sophisticated requirements for the app that such a thing becomes more
useful. This means that the data sources themselves can be accumulated
slowly but the interface to support them should be relatively easy.
> > Closures are excellent in hiding implementation details of simple
> > operations, and I think in this case they fit quite well. The system
> > can even be written to work just fine without the user using closures
> > if they're using CGI.pm, as in my previous example.
I think but am not sure that closures likely also have better performance
than method lookups. If this is the case, it could make sense to support a
few data sources that need high performance because of their common use:
CGI.pm and Apache::Request. Yet provide the extensibility for other
developers to inject their own data sources into the chain using an
Object-based API.
Maybe someone else could comment on the technical merit of closure vs
objects as well as the way in which they have been expecting the widgets to
get populated? Is what I am saying make sense?
Thanks,
Gunther
