John Porter wrote:
>
> Hildo Biersma wrote:
> >
> > I think such modules are a bad idea, because their functionality is
> > typically restricted.
>
> Oh? Where do you get that idea?
Think about it. If a module supports both an OO and a procedural
interface, the procedural interface either requires 'handles' (objects
by another name) or can have only one active 'object' at any time (as in
that case the state has to live in the module). An example of this is
the CGI module.
Now, if a module only supports one active caller at a time, any user of
that module is bascially forced to hope no other portion of the program
(say, any random CPAN module) doesn't use the module in the same non-OO
way. Not a good idea...
IMHO, mixing procedural and OO interfaces to the same module is a bad
idea. Promoting it in the language is not wise.
>
> > Altering the language to make that easier seems a
> > bad idea to me.
>
> On the contrary: altering *anything* about Perl to make
> something easier is quite in keeping with Perl's philosophy.
Perl should not make bad design or bad practice easier. That's why we
are looking at adding more (though optional) strict-ness, type checking,
compile-time safety, etc.
> Look, it's only the difference wbetween
>
> sub meth {
> my $self = shift;
>
> and
>
> sub meth {
> my $self = this;
Once again, disagree. I think Damian's approach, with 'use invocant
"this";", is more flexible and elegant.
But hey, I know this is a religious issue. I'll be able to live with
Larry's final decision...
Hildo
