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
I was looking for some solution to improve debugging of CGI scripts.
A couple of people pointed my attention to ptkdb. So, a couple of
remarks:
* The debugger is very good and should be made a recommended part of
any installed package, at least on X systems.
* Still a better simulation of WWW s
"Roman M . Parparov" wrote:
>
> I was looking for some solution to improve debugging of CGI scripts.
>
> A couple of people pointed my attention to ptkdb. So, a couple of
> remarks:
>
> * The debugger is very good and should be made a recommended part of
> any installed package, at least on X s
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
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 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
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, 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
Philip Newton wrote:
>
> 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
> overdo
On Wed, Aug 09, 2000 at 11:41:20AM +0100, Hildo Biersma wrote:
> Philip Newton wrote:
> >
> > 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
On Wed, 09 Aug 2000 11:41:20 +0100, Hildo Biersma wrote:
>Could we agree on the idea that CGI.pm should be split up?
No. I could agree that
CGI->somemethod(@args);
would do exactly the same as
CGI::somemethod(@args);
i.e. no difference between function calls and class methods
Bart Lateur wrote:
>
> No. I could agree that
>
> CGI->somemethod(@args);
>
> would do exactly the same as
>
> CGI::somemethod(@args);
>
> i.e. no difference between function calls and class methods, unless the
> method explicitely wants to know.
>
> Why make module authors'
On Wed, 09 Aug 2000 13:58:34 +0100, Hildo Biersma wrote:
>Yikes. Class method calls should perform inheritance, subroutine calls
>should not.
I agree with that.
>Altering the language to make the two look the same is a bad
>idea, because it breaks, fatally, as soon as the class supports more
>
On Wed, Aug 09, 2000 at 02:08:09PM +0200, Bart Lateur wrote:
> On Wed, 09 Aug 2000 11:41:20 +0100, Hildo Biersma wrote:
>
> >Could we agree on the idea that CGI.pm should be split up?
>
> No. I could agree that
>
> CGI->somemethod(@args);
>
> would do exactly the same as
>
> CGI::
On Wed, Aug 09, 2000 at 03:26:56PM +0200, Bart Lateur wrote:
> On Wed, 09 Aug 2000 13:58:34 +0100, Hildo Biersma wrote:
>
> >Yikes. Class method calls should perform inheritance, subroutine calls
> >should not.
>
> I agree with that.
>
> >Altering the language to make the two look the same is
On Wed, 9 Aug 2000 14:26:25 +0100, Graham Barr wrote:
>That is being considered. IF that does become part of the language I could
>see subs do something like
>
> if (defined $SELF) {
>called as a method
> }
> else {
>called as a sub
> }
That was my idea. The current unfixable bug I
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
> "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
18 matches
Mail list logo
