[Graham Barr wrote]
> So what do most people think
>
> 1. OK
> 2. Choose one
> 3. Have both, but in separate modules
>
> Someone should probably write an RFC if it is to be either 2 or 3
[this isn't an RFC but...]
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.
Currently, module authors choose the interface to be whatever they think
best (I guess, I'm not a module author :-). Or do both if that is their
preference (CGI and File::Spec).
As a general principle for stblib and CPAN, runtime decision feels bad to
me on the grounds of performance and additional cruft in each sub. I guess
either or both of these shortcomings might be addressed by new language
features/optimisations.
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).
Additionally, it may come about that some modules don't fit well with one
of the interfaces and so would stay implemented only in one way.
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.
- OO interface in name space Foo::Object or Foo::OO, except for the
constructor which exists as Foo::new (but returns an object blessed into
Foo::OO).
It would even be possible to hack support for this into the language, so
things like 'isa' would know about the convention. This could avoid the
inheritance check Graham proposed in his original email with this idea.
regards,
jb
