Re: How to implement both object->method and module::function interfa ce?
> "HB" == Hildo Biersma <[EMAIL PROTECTED]> writes: HB> There's a reason people use objects - if only to give the user a handle HB> to wrap the module's state. Any module that supports both OO and HB> procedural usage is basically a singleton - only one instance exists at HB> any one time (at least in procedural mode). For most modules, this HB> doesn't and shouldn't make sense. Sorry, this doesn't make sense. Please explain the difference between $foo->twiddle and twiddle $foo Or to go to a more specific domain $fh = new File::Text "blah" open($fh, "blah") $txt = $fh->read$txt = <$fh> etc. There is nothing preventing a procedural interface. One only needs a handle. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: How to implement both object->method and module::function interfa ce?
Chaim Frenkel wrote: > > > "HB" == Hildo Biersma <[EMAIL PROTECTED]> writes: > > HB> There's a reason people use objects - if only to give the user a handle > HB> to wrap the module's state. Any module that supports both OO and > HB> procedural usage is basically a singleton - only one instance exists at > HB> any one time (at least in procedural mode). For most modules, this > HB> doesn't and shouldn't make sense. > > Sorry, this doesn't make sense. Please explain the difference between > > $foo->twiddle and twiddle $foo > > Or to go to a more specific domain > > $fh = new File::Text "blah" open($fh, "blah") > $txt = $fh->read$txt = <$fh> > > etc. > > There is nothing preventing a procedural interface. One only needs a > handle. The original discussion was in the context of providing the same API for object and method calls. Of course I am aware that subroutines, using handles, can do the same as objects - after all, that's the way objects are implemented. of objects. To get back at my earlier statement: if you want to provide the same API for object calls and procedural calls, in the fashion of CGI, where the procedural interface does not provide a handle, then you're basically tied to a singleton. Hildo
Re: How to implement both object->method and module::function interfa ce?
On Wed, 9 Aug 2000, Hildo Biersma wrote: > Persoanlly, I think both CGI.pm and File::Spec should be OO modules. And I think CGI.pm should be procedural module :-). (I have no experience with File::Spec, so can't comment on it.) I think OO is sometimes overdone. I don't always want to have to instantiate an object just to call a method when it's not obvious why this method couldn't just be a normal subroutine. > Having said that, I would not mind CGI.pm being a procedural front-end > to an CGI::Object module - I'd just use the latter. And I would use the former. And ISTR a rumour that said that Lincoln Stein prefers or recommends the procedural method, even though the docs use OO examples. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>
Re: How to implement both object->method and module::function interfa ce?
Graham Barr wrote: > > Ah, I forgot about CGI. So there is at least two. > > 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 Persoanlly, I think both CGI.pm and File::Spec should be OO modules. Having said that, I would not mind CGI.pm being a procedural front-end to an CGI::Object module - I'd just use the latter. People that know how to use the OO-interface to CGI.pm are more likely to be able to change their 'use CGI' statement than the vast hordes of cut&paste procedural CGI programmers. Hildo
Re: How to implement both object->method and module::function interfa ce?
On Wed, Aug 09, 2000 at 08:40:32AM +0100, Hildo Biersma wrote: > IMHO, what the CGI module should have done is to (a) force people to use > OO mode or (b) split into a procedural and an OO module, possibly > generated from a common source code. Supporting both at run-time is > bizarre. Internally, and from an efficiency standpoint, it is bizarre, but from an interface standpoint it works rather well, and makes sense for the domain it's in. With a CGI query you have one set of data to work with (the parameters as taken from STDIN and the environment). The only time you need instance information is when you pull query data from a file, which isn't done too often from what I've seen. Splitting the interfaces up into seperate modules isn't a bad idea, though, provided one (the procedural module) uses the other (the OO module). Maintaining, or even generating, seperate code bases would be annoying. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: How to implement both object->method and module::function interfa ce?
On Wed, Aug 09, 2000 at 08:40:32AM +0100, Hildo Biersma wrote: > Jonathan Scott Duff wrote: > > > Perhaps. But I believe that all of the modules provided as part of > > the standard perl distribution should have both procedural and OO > > interfaces where possible. CGI.pm does this in the best way the > > author knew how. In perl 6 we'll (hopefully!) have Damian Conway's > > want() that'll make it a little easier :-) > > I sure hope not! > > There's a reason people use objects - if only to give the user a handle > to wrap the module's state. Any module that supports both OO and > procedural usage is basically a singleton - only one instance exists at > any one time (at least in procedural mode). For most modules, this > doesn't and shouldn't make sense. > > IMHO, what the CGI module should have done is to (a) force people to use > OO mode or (b) split into a procedural and an OO module, possibly > generated from a common source code. Supporting both at run-time is > bizarre. Ah, I forgot about CGI. So there is at least two. 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 Graham.
Re: How to implement both object->method and module::function interfa ce?
On Tue, Aug 08, 2000 at 11:36:38PM +0200, Bart Lateur wrote: > On Tue, 8 Aug 2000 14:22:20 -0500 , Garrett Goebel wrote: > > >What's the conventional wisdom on creating a module that supports both an OO > >and non-OO interface? Are there any CORE or CPAN modules to serve as a > >textbook, or is the anwser "Don't do that"? > > > >I've got some code that checks the first parameter passed to see if it is a > >reference, assumes any reference is an object reference... and then proceeds > >accordingly. -It feels pretty sloppy, but it works. > > Gee, I wonder what this is doing on the Perl6 mailing lists. But, maybe > there are some lessons to be learned, so... Well yes. We do have one such module, File::Spec. So the question is probably valid in that should we have this kind of API in the stdlib, or should we just stick with one or the other or should it be two modules. Graham.
Re: How to implement both object->method and module::function interfa ce?
Jonathan Scott Duff wrote: > Perhaps. But I believe that all of the modules provided as part of > the standard perl distribution should have both procedural and OO > interfaces where possible. CGI.pm does this in the best way the > author knew how. In perl 6 we'll (hopefully!) have Damian Conway's > want() that'll make it a little easier :-) I sure hope not! There's a reason people use objects - if only to give the user a handle to wrap the module's state. Any module that supports both OO and procedural usage is basically a singleton - only one instance exists at any one time (at least in procedural mode). For most modules, this doesn't and shouldn't make sense. IMHO, what the CGI module should have done is to (a) force people to use OO mode or (b) split into a procedural and an OO module, possibly generated from a common source code. Supporting both at run-time is bizarre. Hildo
Re: How to implement both object->method and module::function interfa ce?
On Tue, Aug 08, 2000 at 11:36:38PM +0200, Bart Lateur wrote:
> My idea is: "Don't do it". Let me point to just one example: CGI.pm.
[ snip ]
> This is a bug waiting to happen. Suppose you call it as a function, but
> with a literal string:
>
> $x = param('x');# Will work
> $cgi = param('CGI');# Oops! Major goof here!
>
> It will barf on the latter, because the sub "self_or_default" will think
> it is called as a class method, but it isn't.
But that's the *only* string for which it screws up. Does CGI.pm not
document that you can't have a parameter named 'CGI'?
> Lesson to be learned: this is a bug caused by poor design.
Perhaps. But I believe that all of the modules provided as part of
the standard perl distribution should have both procedural and OO
interfaces where possible. CGI.pm does this in the best way the
author knew how. In perl 6 we'll (hopefully!) have Damian Conway's
want() that'll make it a little easier :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: How to implement both object->method and module::function interfa ce?
On Tue, Aug 08, 2000 at 02:22:20PM -0500, Garrett Goebel wrote: > What's the conventional wisdom on creating a module that supports both an OO > and non-OO interface? Are there any CORE or CPAN modules to serve as a > textbook, or is the anwser "Don't do that"? > > I've got some code that checks the first parameter passed to see if it is a > reference, assumes any reference is an object reference... and then proceeds > accordingly. -It feels pretty sloppy, but it works. I don't think there's conventionial wisdom to doing this, it depends entirely on your application. The problem is that if you're using OO you have a nice little reference implicitly passed around that you can store state information and such in. It's difficult to move this over to a purely procedural design, unless your application allows for it in some way. If you can manage it intelligently, the answer is most definitely "do that!". Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: How to implement both object->method and module::function interfa ce?
Garrett Goebel <[EMAIL PROTECTED]> writes: >What's the conventional wisdom on creating a module that supports both an OO >and non-OO interface? Are there any CORE or CPAN modules to serve as a >textbook, or is the anwser "Don't do that"? Tk does it - which can be taken either way ;-) > >I've got some code that checks the first parameter passed to see if it is a >reference, assumes any reference is an object reference... and then proceeds >accordingly. -It feels pretty sloppy, but it works. It is either fragile or slow depending how picky your validator gets. I tend to find it makes sense to not use the _same_ sub in both interfaces. Rather have sub Foo # (say) the method and sub foo # the functional interface Then implement one in terms of the other. > >Garrett -- Nick Ing-Simmons
Re: How to implement both object->method and module::function interfa ce?
On Tue, 8 Aug 2000 14:22:20 -0500 , Garrett Goebel wrote:
>What's the conventional wisdom on creating a module that supports both an OO
>and non-OO interface? Are there any CORE or CPAN modules to serve as a
>textbook, or is the anwser "Don't do that"?
>
>I've got some code that checks the first parameter passed to see if it is a
>reference, assumes any reference is an object reference... and then proceeds
>accordingly. -It feels pretty sloppy, but it works.
Gee, I wonder what this is doing on the Perl6 mailing lists. But, maybe
there are some lessons to be learned, so...
My idea is: "Don't do it". Let me point to just one example: CGI.pm.
Probably one of the most used modules, I might add. Open the source, and
scroll down till you find the definition for self_or_default, around
line 317 ($VERSION = 2.56). Oh hell, here it is:
sub self_or_default {
return @_ if defined($_[0]) && (!ref($_[0])) &&
($_[0] eq 'CGI');
unless (defined($_[0]) &&
(ref($_[0]) eq 'CGI' || UNIVERSAL::isa($_[0],'CGI'))
# slightly optimized for common case
) {
$Q = $CGI::DefaultClass->new unless defined($Q);
unshift(@_,$Q);
}
return @_;
}
Excuse me for the rewrapping. This sub is called at the start of every
single method, I think. It serves to distinguish between a plain sub
call, and a class or method call. If it's a method call, the name of the
"default class" is prepended to the arguments list.
This is a bug waiting to happen. Suppose you call it as a function, but
with a literal string:
$x = param('x');# Will work
$cgi = param('CGI');# Oops! Major goof here!
It will barf on the latter, because the sub "self_or_default" will think
it is called as a class method, but it isn't.
Lesson to be learned: this is a bug caused by poor design. Perhaps, a
special global variable -- local'ized, of course -- e.g. $SELF, ought to
have been set before the sub is called, to either the object (object
method) or class name (class method); or undef(), if called as a regular
function. The object/class should not have been unshifted unto @_.
Let's do better with Perl6.
p.s. Gee, if Perl6 is going to be so radically different than Perl5,
perhaps we need a new pragma:
use perl6;
or, in contrast:
use perl5;
which could turn on/off the backward compatibility mode.
--
Bart.
