> "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
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 insta
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 ins
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 shou
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.
Internall
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
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 t
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 Conw
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
> $
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
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 go
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
12 matches
Mail list logo
