Re: How to implement both object->method and module::function interface?
Graham Barr wrote: > > This would > > appear largely transparent to the user, right up until they tried to do > > isa() or ref() tests on the object. > > But that is the catch. Now if the language was to give us a way to support > both in the same package in an efficient way, so much the better. > > Graham. Or if the language allowed us stronger "typing" than associating an associative array with a set of methods.
Re: How to implement both object->method and module::function interface?
On Tue, Aug 15, 2000 at 04:59:19PM -0800, Michael Fowler wrote: > On Tue, Aug 15, 2000 at 12:33:15PM +0100, Tim Bunce wrote: > > On Mon, Aug 14, 2000 at 11:30:28AM -0500, Jonathan Scott Duff wrote: > > > use Foo;# like CGI.pm, morphs on demand > > > > > > use Foo;# procedural Foo > > > use OOFoo; # OO Foo > > > > > > use Foo ':procedural'; # default if ommitted. > > > use Foo ':OO'; > > > > > > use Foo;# equivalent to Foo::procedural > > > use Foo::procedural; > > > use Foo::OO; > > > > > > use OOP;# sets some magic variable. > > > use Foo;# Now OO rather than procedural > > > > I don't think you can make much valuable progress down that road till > > we know what Larry's thinking about how to support multiple installed > > versions of a module and multiple implementations of the same 'interface'. > > > > This is a related issue: multiple interfaces to the same code. > > Which makes me think of the following. You don't need to 'use' a seperate > module for a procedural or OO interface. I disagree, kind of. I think of the name of thing being 'use'd as referencing an interface. (I think that's an important shift in perspective.) I don't much care what happens behind the scenes so long as what gets loaded implements the interface that my module has declared that it needs to 'use'. Now, if you take the view that the named 'interface' that I 'use' contains *both* a procedural and OO interfaces, then we can be in agreement again :-) Tim.
Re: How to implement both object->method and module::function interface?
> There has been some suggestion of perl not putting the object in the argument > list when calling a method, but instead having a special var. > > If that happens we should be able to test the special var for defined-ness > to determine how we were called. > > Just a thought. Perl RFC97 suggests allowing multiple functions with the same name if they are declared to take different arguments. Simplistically, this could be extended to allow a sub to be declared as a 'method' (perhaps by indicating that its first arg was an object of the relevant type, perhaps not). Then you have the method call and procedural call in the same namespace with the same name but different function signatures. jb
Re: How to implement both object->method and module::function interface?
On Tue, Aug 15, 2000 at 03:17:36PM -0400, Chaim Frenkel wrote:
> > "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>
> GB> On Tue, Aug 15, 2000 at 10:14:36AM -0400, Chaim Frenkel wrote:
> >> As much as I'm not for it, would
> >>
> >> having
> >>
> >> sub foo :method {} # In objects vtbl
> >> and
> >> sub foo {} # only if procedural call
> >>
> >> being a valid construct and having perl dispatch appropriately, be
> >> viable?
>
> GB> What does it mean ? Can the first only ever be called as a methoed and the
> GB> second as a procedure ? Will we have to define both foo's ?
>
> That was my suggestion. And the _author_ if supplying a dual mode
> module would define both. Either one in terms of the other in order to
> save coding. Or if there were a good reason, two seperate versions.
>
> As I said I'm not enamoured of this suggestion. But it's a thought.
That needs to be made on -language
> Do you think perl can dynamically create one of the styles from the
> other?
There has been some suggestion of perl not putting the object in the argument
list when calling a method, but instead having a special var.
If that happens we should be able to test the special var for defined-ness
to determine how we were called.
Just a thought.
Graham.
Re: How to implement both object->method and module::function interface?
On Tue, Aug 15, 2000 at 12:33:15PM +0100, Tim Bunce wrote: > I don't think you can make much valuable progress down that road till > we know what Larry's thinking about how to support multiple installed > versions of a module and multiple implementations of the same 'interface'. I think much of the stdlib discussion will depend on decisions taken from the -language list. Which is why I am in no hurry to suggest too many things yet. Graham.
Re: How to implement both object->method and module::function interface?
On Tue, Aug 15, 2000 at 04:59:19PM -0800, Michael Fowler wrote: > Which makes me think of the following. You don't need to 'use' a seperate > module for a procedural or OO interface. The module author could simply > provide a constructor in the procedural module that would require the OO > module in the background, and bless the object into that class. That was where this thread started. > This would > appear largely transparent to the user, right up until they tried to do > isa() or ref() tests on the object. But that is the catch. Now if the language was to give us a way to support both in the same package in an efficient way, so much the better. Graham.
Re: How to implement both object->method and module::function interface?
On Tue, Aug 15, 2000 at 12:33:15PM +0100, Tim Bunce wrote: > On Mon, Aug 14, 2000 at 11:30:28AM -0500, Jonathan Scott Duff wrote: > > use Foo;# like CGI.pm, morphs on demand > > > > use Foo;# procedural Foo > > use OOFoo; # OO Foo > > > > use Foo ':procedural'; # default if ommitted. > > use Foo ':OO'; > > > > use Foo;# equivalent to Foo::procedural > > use Foo::procedural; > > use Foo::OO; > > > > use OOP;# sets some magic variable. > > use Foo;# Now OO rather than procedural > I don't think you can make much valuable progress down that road till > we know what Larry's thinking about how to support multiple installed > versions of a module and multiple implementations of the same 'interface'. > > This is a related issue: multiple interfaces to the same code. Which makes me think of the following. You don't need to 'use' a seperate module for a procedural or OO interface. The module author could simply provide a constructor in the procedural module that would require the OO module in the background, and bless the object into that class. This would appear largely transparent to the user, right up until they tried to do isa() or ref() tests on the object. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: How to implement both object->method and module::function interface?
On Mon, Aug 14, 2000 at 11:30:28AM -0500, Jonathan Scott Duff wrote: > > I'll just make up some alternatives for everyone to shoot at: > > use Foo;# like CGI.pm, morphs on demand > > use Foo;# procedural Foo > use OOFoo; # OO Foo > > use Foo ':procedural'; # default if ommitted. > use Foo ':OO'; > > use Foo;# equivalent to Foo::procedural > use Foo::procedural; > use Foo::OO; > > use OOP;# sets some magic variable. > use Foo;# Now OO rather than procedural I don't think you can make much valuable progress down that road till we know what Larry's thinking about how to support multiple installed versions of a module and multiple implementations of the same 'interface'. This is a related issue: multiple interfaces to the same code. Tim [who's only passing through].
Re: How to implement both object->method and module::function interface?
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> On Tue, Aug 15, 2000 at 10:14:36AM -0400, Chaim Frenkel wrote:
>> As much as I'm not for it, would
>>
>> having
>>
>> sub foo :method {} # In objects vtbl
>> and
>> sub foo {} # only if procedural call
>>
>> being a valid construct and having perl dispatch appropriately, be
>> viable?
GB> What does it mean ? Can the first only ever be called as a methoed and the
GB> second as a procedure ? Will we have to define both foo's ?
That was my suggestion. And the _author_ if supplying a dual mode
module would define both. Either one in terms of the other in order to
save coding. Or if there were a good reason, two seperate versions.
As I said I'm not enamoured of this suggestion. But it's a thought.
Do you think perl can dynamically create one of the styles from the
other?
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: How to implement both object->method and module::function interface?
On Tue, Aug 15, 2000 at 10:14:36AM -0400, Chaim Frenkel wrote:
> As much as I'm not for it, would
>
> having
>
> sub foo :method {} # In objects vtbl
> and
> sub foo {} # only if procedural call
>
> being a valid construct and having perl dispatch appropriately, be
> viable?
What does it mean ? Can the first only ever be called as a methoed and the
second as a procedure ? Will we have to define both foo's ?
Graham.
Re: How to implement both object->method and module::function interface?
As much as I'm not for it, would
having
sub foo :method {} # In objects vtbl
and
sub foo {} # only if procedural call
being a valid construct and having perl dispatch appropriately, be
viable?
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> However, if for method calls the object is moved out into $ME (or whatever)
GB> then this could be an advantage to a dual API. For example
GB> sub i_dont_care_sur_or_method {
GB> # just process @_, ignore $ME
GB> }
GB> sub dual_api {
GB> my $me = ref($ME) ? $ME : $default_obj; # Pkg->dual_api is same as sub-call
GB> # process
GB> }
GB> So I am hoping that we get the object removed from @_ into an predefined
GB> lexical so the sub can more easily determine how it was called with
GB> little expense.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: How to implement both object->method and module::function interface?
On Mon, Aug 14, 2000 at 11:30:28AM -0500, Jonathan Scott Duff wrote:
> > Following Graham's example, we could standardise something like:
> >
> > - Procedural interface in name space Foo::
> > You should not have a procedural sub called 'new' - that is reserved for
> > the OO constructor.
>
> Er, no. Dictations such as these are likely to raise the hackles of
> those same people who would get upset were they told the stdlib should
> be all object oriented or all non-object oriented.
I agree a dictation would be bad.
> I'll just make up some alternatives for everyone to shoot at:
>
> use Foo;# like CGI.pm, morphs on demand
>
> use Foo;# procedural Foo
> use OOFoo; # OO Foo
>
> use Foo ':procedural'; # default if ommitted.
> use Foo ':OO';
>
> use Foo;# equivalent to Foo::procedural
> use Foo::procedural;
> use Foo::OO;
>
> use OOP;# sets some magic variable.
> use Foo;# Now OO rather than procedural
>
> I'm making the tacit assumptions that people will want the procedural
> version by default and that all of the standard modules would have both
> a OO and a procedural interface. In that last example, the OOP module
> would set some variable that all of the standard modules know to look
> to determine if they should put on an OO face or not.
The issue with using tha same namespace is that the performance degrades
because every sub must test if it's first arg is an object and "DWIM"
However, if for method calls the object is moved out into $ME (or whatever)
then this could be an advantage to a dual API. For example
sub i_dont_care_sur_or_method {
# just process @_, ignore $ME
}
sub dual_api {
my $me = ref($ME) ? $ME : $default_obj; # Pkg->dual_api is same as sub-call
# process
}
So I am hoping that we get the object removed from @_ into an predefined
lexical so the sub can more easily determine how it was called with
little expense.
Graham.
Re: How to implement both object->method and module::function interface?
On Mon, Aug 14, 2000 at 11:13:38AM +0100, John Berthels wrote: > I would imagine that having a policy that stdlib is all OO or all non-OO > would upset enough people to be a bad idea. I agree entirely. > So I like (3). With the additional note that if we standardise a method > of doing so then the module authors can, if they so choose, still only > implement one if they follow the guidelines. (Which would allow someone > else to implement the other interface type in terms of the original > author's code). I'd prefer that the standard modules that come with Perl have both procedural and OO interfaces (even if one is just a wrapper around the other) Nine times out of ten I use CGI.pm in a procedural manner, but when I'm saving and restoring varied data, that OO interface sure comes in handy :-) > Following Graham's example, we could standardise something like: > > - Procedural interface in name space Foo:: > You should not have a procedural sub called 'new' - that is reserved for > the OO constructor. Er, no. Dictations such as these are likely to raise the hackles of those same people who would get upset were they told the stdlib should be all object oriented or all non-object oriented. I'll just make up some alternatives for everyone to shoot at: use Foo;# like CGI.pm, morphs on demand use Foo;# procedural Foo use OOFoo; # OO Foo use Foo ':procedural'; # default if ommitted. use Foo ':OO'; use Foo;# equivalent to Foo::procedural use Foo::procedural; use Foo::OO; use OOP;# sets some magic variable. use Foo;# Now OO rather than procedural I'm making the tacit assumptions that people will want the procedural version by default and that all of the standard modules would have both a OO and a procedural interface. In that last example, the OOP module would set some variable that all of the standard modules know to look to determine if they should put on an OO face or not. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: How to implement both object->method and module::function interface?
[Graham Barr wrote] > 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 [this isn't an RFC but...] I would imagine that having a policy that stdlib is all OO or all non-OO would upset enough people to be a bad idea. Currently, module authors choose the interface to be whatever they think best (I guess, I'm not a module author :-). Or do both if that is their preference (CGI and File::Spec). As a general principle for stblib and CPAN, runtime decision feels bad to me on the grounds of performance and additional cruft in each sub. I guess either or both of these shortcomings might be addressed by new language features/optimisations. So I like (3). With the additional note that if we standardise a method of doing so then the module authors can, if they so choose, still only implement one if they follow the guidelines. (Which would allow someone else to implement the other interface type in terms of the original author's code). Additionally, it may come about that some modules don't fit well with one of the interfaces and so would stay implemented only in one way. Following Graham's example, we could standardise something like: - Procedural interface in name space Foo:: You should not have a procedural sub called 'new' - that is reserved for the OO constructor. - OO interface in name space Foo::Object or Foo::OO, except for the constructor which exists as Foo::new (but returns an object blessed into Foo::OO). It would even be possible to hack support for this into the language, so things like 'isa' would know about the convention. This could avoid the inheritance check Graham proposed in his original email with this idea. regards, jb
Re: How to implement both object->method and module::function interface?
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 showed in CGI.pm would
easily be fixed. However, Hildo's argument WRT inheritance makes me less
convinced that it is the ultimate ideal.
--
Bart.
Re: How to implement both object->method and module::function interface?
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 a bad
> >idea, because it breaks, fatally, as soon as the class supports more
> >than one object at a time.
>
> Then, the alternative method would be NOT to use the word "sub" any more
> in order to make a method.
>
> method param {
> ... # this is a method, including inheritance
> }
> sub param {
> ... # this is an ordinary function; no inheritance
> }
>
> Both could well coexist withing the same module; but they can't both be
> CODE refs.
This is a language issue, please take it to the perl-language mailing list.
Graham.
Re: How to implement both object->method and module::function interface?
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::somemethod(@args);
>
> i.e. no difference between function calls and class methods, unless the
> method explicitely wants to know.
Either you are asking for a language change here, or you are suggesting that
the dual API remain so that $cgi->somemethod(@args); calls the same
sub as above. Which is what I think people want to get away from.
> Why make module authors' life even more miserable?
>
> Passing the class/object in a magic variable, e.g. $SELF, instead of in
> the arguments list, is one way.
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
}
Graham.
Re: How to implement both object->method and module::function interface?
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
>than one object at a time.
Then, the alternative method would be NOT to use the word "sub" any more
in order to make a method.
method param {
... # this is a method, including inheritance
}
sub param {
... # this is an ordinary function; no inheritance
}
Both could well coexist withing the same module; but they can't both be
CODE refs.
--
Bart.
Re: How to implement both object->method and module::function interface?
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' life even more miserable? > > Passing the class/object in a magic variable, e.g. $SELF, instead of in > the arguments list, is one way. Yikes. Class method calls should perform inheritance, subroutine calls should not. 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 than one object at a time. Instead of changing the language to make a crufty interface work, the interface should be changed... Hildo
Re: How to implement both object->method and module::function interface?
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, unless the method explicitely wants to know. Why make module authors' life even more miserable? Passing the class/object in a magic variable, e.g. $SELF, instead of in the arguments list, is one way. -- Bart.
Re: How to implement both object->method and module::function interface?
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
> > 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.
>
> Could we agree on the idea that CGI.pm should be split up?
Why not write an RFC to that effect, but don't limit it to CGI. Include
any other modules which provide a dual interface.
Personally I would not mind allowing
$cgi = CGI->new
which actually returned a CGI::Object. Of course CGI::new would have
to check that the first arg was 'CGI' and croak otherwise as this would
indicate an @ISA set to CGI instead of CGI::Object. ie
sub new {
my $pkg = shift;
croak "Bad inheritance of CGI via $pkg"
unless $pkg eq 'CGI';
require CGI::Object;
CGI::Object->new(@_);
}
Graham.
Re: How to implement both object->method and module::function interface?
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 > 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. Could we agree on the idea that CGI.pm should be split up? Hildo
