Re: How to implement both object->method and module::function interface?

On Mon, Aug 14, 2000 at 11:13:38AM +0100, John Berthels wrote:
> I would imagine that having a policy that stdlib is all OO or all non-OO
> would upset enough people to be a bad idea.

I agree entirely.

> So I like (3). With the additional note that if we standardise a method
> of doing so then the module authors can, if they so choose, still only
> implement one if they follow the guidelines. (Which would allow someone
> else to implement the other interface type in terms of the original
> author's code).

I'd prefer that the standard modules that come with Perl have both
procedural and OO interfaces (even if one is just a wrapper around the
other)  Nine times out of ten I use CGI.pm in a procedural manner, but
when I'm saving and restoring varied data, that OO interface sure
comes in handy  :-)

> Following Graham's example, we could standardise something like:
> 
> - Procedural interface in name space Foo::
> You should not have a procedural sub called 'new' - that is reserved for
> the OO constructor.

Er, no.  Dictations such as these are likely to raise the hackles of
those same people who would get upset were they told the stdlib should
be all object oriented or all non-object oriented.

I'll just make up some alternatives for everyone to shoot at:

	use Foo;			# like CGI.pm, morphs on demand

	use Foo;			# procedural Foo
	use OOFoo;			# OO Foo

	use Foo ':procedural';		# default if ommitted. 
	use Foo ':OO';

	use Foo;			# equivalent to Foo::procedural
	use Foo::procedural;		
	use Foo::OO;

	use OOP;			# sets some magic variable.
	use Foo;			# Now OO rather than procedural

I'm making the tacit assumptions that people will want the procedural
version by default and that all of the standard modules would have both
a OO and a procedural interface.  In that last example, the OOP module
would set some variable that all of the standard modules know to look
to determine if they should put on an OO face or not.

-Scott
-- 
Jonathan Scott Duff
[email protected]