On Sat, Sep 16, 2000 at 02:57:01PM -0700, Nathan Wiger wrote:
> > Ooop, didn't even notice and didn't see the discussion. Let me see if
> > I missed anything... I didn't discuss class methods as opposed to
> > object methods. Will ponder.
>
> It's really dicey. I think it's probably bad, because there's no way to
> tell here:
>
> print "Your name is Class->name";
>
> Whether Class is 'Class' or Class(). The phrase "avoid at all costs"
> comes to mind. ;-)
Hmmm... we could require that the trailing parens be there:
print "Your name is Class->name()";
This has precedence in dynamic method calls, ie. C<$obj->$meth()>
where the parens are used to disambiguage the statement.
> !@()*&!@@!$(*&!_)(@*_!
That should compile cleanly in Perl 6.
> > C<eval "require $class"> isn't that hard, but I wouldn't mind seeing a
> > more obvious way.
>
> Nothin' leaps out. My brain hurst.
How's about this?
package UNIVERSAL;
sub require {
my($class) = shift;
my $return = eval "CORE::require($class)";
die $@ if $@;
return $return;
}
package main;
my $class = 'CGI';
$class->require;
print $class->header;
It would be nice if there could be a corresponding use() but that
would be in conflicting with the run-time nature of $class and method
calls. Still, this:
BEGIN { $class->require; $class->import } # use $class
is more obvious than this:
BEGIN { eval "require $class"; $class->import } # use $class
and has the virtue of preserving the death if the require() fails.
(Most people forget to check $@ when they use the eval/require trick)
> > This combines the problems of symbolic references PLUS busting
> > encapsulation. Shouldn't be easy.
>
> I'd just settle for easiER than this:
>
> &{"${mypkg}::do_stuff"}(@a) # &{$mypkg.'::'."do_stuff"}(@_) too
>
> It only busts encapsulation if you're using it as an object. If you just
> want to get to a function without importing it, then you've gotta type
> lots.
OO isn't the only coding style which involves encapsulation, but I'll
concede the point.
However, how often do you find yourself with the name of a package in
a variable and the function hardcoded? Seems a strange occasion since
rarely will two non-OO packages implement interchangable functions.
If you find yourself needing that sort of thing often, perhaps it
should be rewritten as OO.
> I'm feelin' an RFC retraction comin' on...
[Schwern rubs his black gloved hands gleefully and cuts another notch
into his black hat.]
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Long, long time ago, in a far away galaxy, cells were formed. Cells are
building blocks of different chemicals.
--Alex Chiu, Immortality Guy
