Matthew Simon Cavalletto <[EMAIL PROTECTED]> writes:
> On Dec 31, 2004, at 2:24 PM, Terrence Brannon wrote:
>
>> succint is worthwhile. The "magical" version of the hello_world.pm
>> program is:
>>
>> $tree->name('terrence brannon')->date('5/11/1969')->as_HTML;
>>
>> The "plain Jane" version is:
>>
>> $tree->get_name->replace_content('terrence brannon')
>> ->get_date->replace_conent('5/11/69);
>
> It's not clear to me that either of these named-accessor,
> mutator-chaining interfaces is the optimum idiom; wouldn't the
> following be clearer?
>
> $tree->replace_content_elements(
> 'name' => 'terrence brannon',
> 'date' => '5/11/69
> );
> print $tree->as_HTML;
>
>> In fact, it is nice to know that all tree processing
>> actions will be handled like this:
>>
>> $tree->$id_name->$library_method(@method_args);
>
> It seems more natural to me to treat the ID as data, along these lines:
>
> $tree->$library_method($id_name => @method_args);
>
> Why select an interface that forces you to generate methods for every
> ID'd element?
You have a better design but I am subclassing from HTML::Tree. When you work
with HTML::Tree, each method typically receives the tree as its first
argument. So the first thing my methodmaker did was go find the right
tree so it could be passed to other methods. In addition,
HTML::ElementTable (by Matthew Sisk), and HTML::Element::Library (soon
to be uploaded) all revolve around the notion of give me a tree and I
act as advertised.
IDs as look_down criteria are just one thing that HTML::Tree can do
look_down()s on. It can look down on tags, text, closures. For the
purposes of my limited domain, all I need are id tags. But I would
need a front-end to every HTML::Tree method which did
$tree->look_down(id => $id_name) # locate the subtree
->$library_method(@method_args); # operate on the tree
before calling the method. For example HTML::ElementExtended contains
the shortcut method replace_content($tree, $new_content). So if I
wrote a manual boilerplate in Seamstress which converted
$tree->replace_content($id_name => $new_content)
to
$tree->look_down(id => $id_name)->replace_content($new_content)
then I could have the interface most suited for Seamstress convert to
the interface most common outside of Seamstress.
But to me that is less natural than
$tree->get_id_name->replace_content($new_content)
> (And what happens when my HTML designer gives me a template with IDs
> named 'new' or 'delete'?)
Razor-sharp assessment, Simon. Thanks a lot for the input. I never
thought of that pitfall. But maybe that's why there should be no
methods which are not prefaced with get_$id. You have settled that
issue for me once and for all: to hell with method names not prefixed
with get_ or set_
> >
> More generally, I would side with Aristotle's position against mutator
> chaining, set forth at <http://perlmonks.org/index.pl/417872>,
> particularly in cases which seem to mix mutators with sub-object
> accessors -- are you really calling get_date() on the result of
> replace_content(), as shown in the "plain" example above? Yikes!
It does work as long as it is passed the root tree. But I see your
point. If replace_content() is called with a subtree and returns a
subtree, then get_date() will fail.
--
Carter's Compass: I know I'm on the right track when,
by deleting something, I'm adding functionality.
_______________________________________________
sw-design mailing list
[email protected]
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
