Hildo Biersma wrote:
>
> Look, there's a reason we have objects - they encapsulate state. If a
> module supports objects and procedural calls, in the latter case it will
> either need a handle to the state (objects by anoither name), or will
> store the state internally. If the module stores the state internally,
> then you can only have one active caller at a time. If another module
> also uses the procedural interface, and also expects to be the only
> user, things break.
But that is all highly module-implementation dependent.
{
local $Foo::current_object = $my_obj;
Foo::splut();
}
Also, as in the case of CGI, you can mix safely:
if ( param('name') ) {
print $q->b( "howdy" );
}
Sounds to me like you're really arguing against procedural modules
in general, because they lack the strengths OO provides.
> my $dup = open("</etc/motd")->dup();
> for (1..2) { $dup->readline(); }
>
> And now, suddenly, the readline() method breaks, because it doesn't have
> two levels of caller.
Actually, Hildo, you've found the fault in the whole proposal:
there is no "call stack" of objects here, even in constructs like
open("</etc/motd")->dup->readline;
By the time readline is called, dup and open have both exited.
All readline can see is the value that dup returned.
--
John Porter
We're building the house of the future together.
