On Mon, Sep 18, 2000 at 12:53:32PM -0400, Michael G Schwern wrote:
> On Mon, Sep 18, 2000 at 10:16:46AM -0400, John Porter wrote:
> > Hildo Biersma wrote:
> > > IMHO, mixing procedural and OO interfaces to the same module is a bad
> > > idea. Promoting it in the language is not wise.
> >
> > O.k
On Mon, Sep 18, 2000 at 10:16:46AM -0400, John Porter wrote:
> Hildo Biersma wrote:
> > IMHO, mixing procedural and OO interfaces to the same module is a bad
> > idea. Promoting it in the language is not wise.
>
> O.k., but that's not the same as disallowing it. Perl is not a B&D
> language.
I
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 th
Hildo Biersma wrote:
> > > I think such modules are a bad idea, because their functionality is
> > > typically restricted.
>
> An example of this is the CGI module.
You consider CGI.pm an example of a module with restricted functionality?
> IMHO, mixing procedural and OO interfaces to the same
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Objects: C pragma
>
> =head1 VERSION
>
> Maintainer: Damian Conway <[EMAIL PROTECTED]>
> Date: 14 September 2000
> Mailing List: [EMAIL PRO
Nathan Wiger wrote:
>
> > I think such modules are a bad idea, because their functionality is
> > typically restricted.
>
> What, you mean like CGI.pm ?! :-)
Yes, restricted. If you use the procedural interface to a module that
supports both OO and procedural interfaces, you're basically at th
John Porter wrote:
>
> Hildo Biersma wrote:
> >
> > I think such modules are a bad idea, because their functionality is
> > typically restricted.
>
> Oh? Where do you get that idea?
Think about it. If a module supports both an OO and a procedural
interface, the procedural interface either requ
> I think such modules are a bad idea, because their functionality is
> typically restricted.
What, you mean like CGI.pm ?! :-)
> This is a benefit? Forcing multiple authors to use the same 'this' or
> 'self' name across modules is not the perl way
Well, from this logically follows that "forci
Hildo Biersma wrote:
>
> I think such modules are a bad idea, because their functionality is
> typically restricted.
Oh? Where do you get that idea?
> Altering the language to make that easier seems a
> bad idea to me.
On the contrary: altering *anything* about Perl to make
something easier
On 14 Sep 2000, at 14:18, Nathan Wiger wrote:
> Before you balk at #1 in favor of religious flexibility, please consider
> how unmaintainable Perl code would be if @ARGV, or $AUTOLOAD, or STDERR,
> or @INC, or chomp(), or split(), or any other widely-used variable or
> function was renameable. If
Graham Barr wrote:
>
> One of the benefits I was hoping to get from having a variable hold
> the invocant is the ability for the invocant to be undef if the sub
> was not called as a method.
Um, functions can return undef too, ya know. :-)
--
John Porter
On Thu, Sep 14, 2000 at 08:10:54PM -, Perl6 RFC Librarian wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Objects: C pragma
>
> =head1 VERSION
>
> Maintainer: Damian Conway <[EMAIL PROTECTED]>
> Date: 14 September 2000
> Mail
Nathan Wiger wrote:
> >
> > and this may, indeed, be sufficient.
>
> Remember, this still won't solve the problem of a module whose functions
> can handle both OO and function-oriented calls - and yes, I have many
> that do this. :-)
I think such modules are a bad idea, because their functional
> Mailing List: [EMAIL PROTECTED]
Just to nitpick, this should probably be perl6-language-objects
> sub method ($self, @args) {
> ...
> }
>
> and this may, indeed, be sufficient.
Remember, this still won't solve the problem of a module whose functions
can hand
> Uh, that should "invocand", should it not?
No.
> Unless the OO community has already decided this issue unbeknownst to me...
As of Camel III "invocant" is the way to refer to the reference to an object
through which a method is called. I.e. the reference that inevitably ends up
in $s
> This RFC proposes that, as in Perl 5, the invocant of a method should be
> normally available to the method as $_[0], but that it can be
> automaticaly stripped from @_ and accessed via either a subroutine
> or a variable, using the C pragma.
Uh, that should "invocand", should it not? In
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects: C pragma
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 14 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 223
Version: 1
Status: Developing
=head1 ABSTRACT
17 matches
Mail list logo
