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?
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?
chaim
"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?
"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
--
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: 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?
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?
[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 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?
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, 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.
