On Mon, Aug 14, 2000 at 11:30:28AM -0500, Jonathan Scott Duff wrote:
> > 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 agree a dictation would be bad.
> 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.
The issue with using tha same namespace is that the performance degrades
because every sub must test if it's first arg is an object and "DWIM"
However, if for method calls the object is moved out into $ME (or whatever)
then this could be an advantage to a dual API. For example
sub i_dont_care_sur_or_method {
# just process @_, ignore $ME
}
sub dual_api {
my $me = ref($ME) ? $ME : $default_obj; # Pkg->dual_api is same as sub-call
# process
}
So I am hoping that we get the object removed from @_ into an predefined
lexical so the sub can more easily determine how it was called with
little expense.
Graham.
