[Petal] [PATCH] Options via constructor rather than package globals

Steve Purkis spurkis at mkdoc.com
Thu Jun 5 15:32:31 BST 2003


On Thursday, June 5, 2003, at 11:01  am, Jean-Michel Hiver wrote:

>> 1. a base class for all Petal objects, ie: Petal::Object, or
>>    Petal::Base.  To begin with, this would contain new() and
>>    _initialize(), which are easily overrided.
>
> I'm not sure if I agree with the concept of 'base classes'. I mean,
> there is one, called UNIVERSAL. It has a few methods like can() and
> isa() but it features no constructors.

Yes, but there aren't many tasks that warrant bunging things into 
UNIVERSAL.

A base class makes sense for two simple reasons:
	1. consistency within a project.
	2. reduces code duplication.


> Until there is a popular CPAN 'base class' that does anything you'd 
> want
> in a base class (constructors, initialization, popular methods...) then
> I'd prefer to stick with implementing a constructor each time.
>
> Maybe Petal objects should inherit from Class::Base?

I doubt a popular CPAN base class will happen - TMTOWTDI. (but see (1) 
above :).


>> 2. cascade-able accessor methods which let you do:
>>
>> 	$template
>> 	  ->language('fr')
>> 	  ->input('HTML')
>> 	  ->output('XHTML');
>
> Now I find this really, really useless :)
>
> I disagree with the idea of constructing an object that is in an
> inconsistent state and setting the state afterwards through some 
> strange
> syntaxic sugar.
>
> I suppose it doesn't cost much to implement... since you don't have to
> use it if you don't want it, it's probably a good idea despite the fact
> that I don't like it :)

I find this technique quite useful, but it has to be applied across a 
project for it to make any difference.  In this case it's up to you - 
Petal is your project.


>> Again, good work.  Lets hope Jean-Michel agrees ;-)
>
> I applied the patch, looked at it, and then tweaked a little bit things
> the way I wanted...
>
> Having the options at an object level did really involve quite a lot of
> changes. So instead of making the rest of Petal code aware of 
> per-object
> options, I changed the process() method to declare the global options
> variables as local and set them to the per-objects options.
>
> It might seem like a bit of a hack but I think it's acceptable and it
> fits in better with the way Petal was designed to start with. Also, the
> patch seemed to fail one test...

That _is_ a bit of a hack - I'd say go 100% OO, or don't bother because 
it will bite you in the behind down the line when you forget one 
'local' ...


> Anyway since I haven't released Petal in a while I'll to a .93 release
> that should sort out the most urgent stuff (including the
> Petal::Hash::VAR bug you pointed out). Meanwhile more deep changes to
> Petal will have to wait...

Waiting is such fun. :)

-Steve



More information about the Petal mailing list