Re: RFC 335 (v1) Class Methods Introspection: what methods does this object support?
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Class Methods Introspection: what methods does this object support? > > =head1 VERSION > > Maintainer: Mark Summerfield <[EMAIL PROTECTED]> > Date: 28 Sep 2000 > Mailing List: [EMAIL PROTECTED] > Number: 335 > Version: 1 > Status: Developing > > =head1 ABSTRACT > > This RFC proposes a new UNIVERSAL method which would be used thus: > > my @method_names = $object->methods(); # OR MyClass->methods(); Nice work. However, I would say that in an OO context there's a case for walking the @ISA Tree to find out all the methods that the class will respond to, say $object->all_methods, after all, in a complex class hierarchy there may be classes that implement only one or two methods that are distinct from the methods of their parent class. Actually, I'd like to see something similar done to Universal::can (though Interface polymorphism may make this less important...) -- Piers
Re: RFC 254 (v1) Class Collections: Provide the ability tooverload classes
On Thu, 28 Sep 2000, David L. Nicol wrote:
[snip]
>sub speak { print "kerokero"; }
>
>foreach (?) { # go through all the methods defined in Frog::Frog
> # I know there is a way to do this but do not know what it is
See RFC 335 (v1): Class Methods Introspection: what methods does this object
support?
> #next if $_ eq speak;
> next if defined \&$_;
> eval "sub $_ { return &Frog::Frog::$_ @_ }";
>};
[snip]
___
Mark Summerfield http://www.netcraft.com/newsfeed
>>Written in my private capacity on my own behalf<<
http://www.perlpress.com (Perl)
http://www.ourobourus.com (Python)
Re: RFC 336 (v1) use strict 'objects': a new pragma for using Java-like objects in Perl
Hi all
Preamble:
1) Everybody: excuse my english, my italian is better but you don't want
me to write in italian :-)
2) Listmaster: excuse this post from an unknown address, I've just
subscribed as [EMAIL PROTECTED];
3) Everybody again: excuse the address @perlguru.com, but I didn't want
my work mailbox filled of ML messages... and that address is free and
works well ;)
Said this, the message.
Jonathan Scott Duff wrote:
>
> On Thu, Sep 28, 2000 at 09:05:52PM -, Perl6 RFC Librarian wrote:
> > =head1 TITLE
> >
> > use strict 'objects': a new pragma for using Java-like objects in Perl
>
> > =head2 protected
> >
> > Just take Conway's RFC 188 and do a s/private/protected/g :-)
>
> "protected" is a very loaded term. What you propose to call protected
> in Perl isn't the same as protected in C++. This will cause
> confusion.
Significance we attribute to "protected" is similar to Java's. Many
languages use the same keyword with different meanings, nor this creates
any ambiguity. Who gets confused by the fact that the "=" operator has
different meanings in C and Pascal, raise your hands :) Leaving the joke
out, "our" protected operator is similar to Java's; we don't want Perl
to become C++ or Java: we just would like to have better objects.
> > =head2 private
> >
> > Like Conway's private operator defined in RFC 188, but accessing an
> > hash key or a method that has been marked as private from outside the
> > defining package should result in a fatal error.
>
> What does this buy us? What is the benefit?
The benefit is: having real (s/real/more realistic/ if you like)
objects: an object's attributes should be accessible only by the object
itself; accesses from outside should happen by means of methods, and
methods are responsible for object's data consistency. Can you
accomplish this with perl 5 without doing weird games with closures?
> > =head2 static
> > Methods not marked as such should return a fatal error if called
> > directly on the class.
>
> Again, where's the benefit?
You have one in the last example of the RFC: you have methods (say:
subs) you can access from a class in an object oriented way. This gives
you more coherence. And you don't need to instanciate objects to use
them, you just use them from the class. Moreover, if you need those
functions in many methods (again, say: subs) you don't have to
instanciate an object and pass it around, nor you have to instanciate
one over and over, nor you use plain functions: you use classes and
methods, coherently.
We hope we explained our point of view. In case we didn't, I'm on this
list now (with a awful address, but -maybe- it doesn't matter).
Ciao
Marco & Stefano
--
_ _
/ ___)| __ \/ ___)/ /| | Marco Marongiu ([EMAIL PROTECTED])
| (___ |/\___ \\__ | Computers & Network Group
\)|_|\_\(/ |_| Phone: +39 070 2796 336
Re: RFC 335 (v1) Class Methods Introspection: what methods does this object support?
Piers Cawley <[EMAIL PROTECTED]> writes: > Actually, I'd like to see something similar done to Universal::can my @methods = $class->can(pattern) where pattern is a perl pattern matching method names. For a full list, use $class->can(); or $class->can(qr/./); -- Johan
RFC 163 (v3) Objects: Autoaccessors for object data structures
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects: Autoaccessors for object data structures
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Last Modified: 29 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 163
Version: 3
Status: Frozen
Original Author: James Mastros <[EMAIL PROTECTED]>
Requires: RFC 279, RFC 337
=head1 ABSTRACT
This RFC proposes three attributes, C<:laccess>, C<:raccess>, and
C<:roacess>, which when used on a blessed object variable,
automatically construct an C, C, or readonly
C autoaccessor, respectively.
=head1 NOTES ON FREEZE
Pretty much everyone liked the basic idea, but the implementation needs
some work. In particular, Michael Schwern pointed out that using
attributes to declare these may not be the best method. B
proposes a use of attributes that would allow them to basically act as
specialized subs, so this concern may be solved. Regardless, it is an
issue that needs revisiting; a package-wide pragma may be the best
solution.
=head1 DESCRIPTION
=head2 Overview
Currently, to hide your data - even simply - you must create subs that
often look something like this:
sub fullname {
my $self = shift;
@_ ? $self->{fullname} = $_[0]
: $self->{fullname};
}
This allows you to compartmentalize your data so that people can then
use it in their programs as:
$r->fullname('Nathan Wiger');
print $r->fullname;
For one or two data pieces, this is ok. But for lots of data, this chews
up a lot of time and code space unnecessarily.
This RFC proposes the attributes C<:laccess>, C<:raccess>, and
$C<:roaccess> which would automate this process. The tags are kept
intentionally separate so that you can manually create an C sub,
but use the attribute to generate an C sub, or vice-versa.
=head2 The :raccess attribute
We'll start with the "easy one", which simply constructs an C
sub. Consider this code:
package Bob;
sub new {
my $class = shift;
my $self = {};
$self->{name} :raccess = undef;
$self->{age} :raccess = undef;
return bless $self, $class;
}
Basically, two new C class methods would be created
automagically:
sub name {
my $self = shift;
@_ ? $self->{name} = $_[0]
: $self->{name};
}
sub age {
my $self = shift;
@_ ? $self->{age} = $_[0]
: $self->{age};
}
These two subs could now be used in any C context by anyone who
used your class:
my $jim = new Bob;
$jim->name('Joe');
$jim->age(42);
print $jim->age;
The benefits are obvious: It's quick and easy, especially if you just
need a simple data wrapper.
=head2 The :roaccess attribute
This works identically to the above sub, with the difference that
modification of its value is not allowed; it is readonly. As such,
the following:
$self->{name} :roaccess = "Nate";
Would create the equivalent of the following sub:
sub name {
my $self = shift;
croak "Attempt to assign to readonly rvalue autoaccessor" if @_;
return $self->{name};
}
As such, you could fetch values but not set them:
print $r->name; # "Nate";
$r->name('Jim');# oops!
The second one should result in an exception being thrown.
=head2 The :laccess attribute
This tag works just like the above, only creating an C sub
instead. So this code:
package JimmyHat;
sub new {
my $class = shift;
my $self = {};
$self->{size} :laccess = undef;
return bless $self, $class;
}
Would basically create the following C sub:
sub size : lvalue {
shift->{size};
}
Which could be used in any C context:
my $raincoat = new JimmyHat;
$raincoat->size = 42;
$raincoat->size++;
Easy enough.
=head2 Specifying the name of the sub
The above cases are fine for simple situations, but often you will have
nested data structures. No fear, you can optionally specify the name of
the sub as an argument to the tag:
package Johnson;
sub new {
my $class = shift;
my $self = {};
$self->{DATA}->{NUMERIC}->{S_size} :raccess('size') = undef;
$self->{DATA}->{STRING}->{PL_name} :laccess('name') = undef;
return bless $self, $class;
}
This would basically have the effect of creating the following two subs:
sub size {
my $self = shift;
@_ ? $self->{DATA}->{NUMERIC}->{S_size} = $_[0]
: $self->{DATA}->{NUMERIC}->{S_size}
}
sub name : lvalue {
shift->{DATA}->{STRING}->{PL_name};
}
Which again, can be used in the appropriate contexts. Note this allows
you to maintain arrayref objects automatically as well:
package Johnson;
sub new {
my $class = shift;
my $self = [];
$self->[0]->[2]->[3] :raccess('size') = undef;
$self->[4]->[1] :laccess('name') = undef;
return bless $self, $class;
}
Although an arrayref is usually not the best data
RFC 174 (v3) Improved parsing and flexibility of indirect object syntax
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Improved parsing and flexibility of indirect object syntax
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Last Modified: 29 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 174
Version: 3
Status: Frozen
=head1 ABSTRACT
Currently, Perl 5 makes a distinction between routines called in the
indirect object vs. function form:
$r = new CGI; # CGI->new
$r = new CGI (@args); # CGI->new(@args)
$r = new(CGI @args); # mail::new(main::CGI(@args))
This causes many problems, such as having to have special prototypes
that translate the optional first argument object into the indirect
object syntax. Special cases like this, and the inability to prototype
print(HANDLE @list);
Have led some to suggest indirect objects be expunged altogether.
However, inflexbility is not the solution to this problem, since there
are many benefits to indirect object syntax. In Perl 6, the distinction
between function and indirect object syntax should be dropped. Instead,
the second form should be automatically translated to the first when
possible. This increased flexibility allows prototyping of key functions
while still being able to take advantage of indirect objects.
=head1 DESCRIPTION
=head2 Indirect objects should be any valid single value
Currently, indirect objects can only be a scalar, block, or bareword.
This RFC proposes that this concept be extended to any valid singular
thingy. So in Perl 6 these:
print $handles{'mainout'} "Hello, world!";
print $output[0] "Hi there!";
Should work as indirect objects. Code references should still have to be
enclosed in blocks, since this is needed to reduce ambiguity between
indirect objects and chained functions.
=head2 Indirect objects should be enclosable in parens
Let's get into a more common example:
print @data;
print(@data);
print STDERR @data;
print(STDERR @data);
Currently, the fact that all of these can coexist contributes to the
fact that CORE::print is not prototypeable/overrideable, which is a bad
thing, obviously. That last one is particularly sticky, since it would
intrinsically be parsed as something like:
CORE::print(main::STDERR(@data));
But now we have to have special rules to deal with this. I'm going to
digress for a moment and skip barewords, coming back to them later.
Assuming that the above became scalar filehandles:
print $STDERR @data;
print($STDERR @data);
We can add a simple parsing rule to convert the second form into the
first:
If the first argument to a function is a scalar value which
is not followed by a comma, then that value is the indirect
object for that function.
So, under this rule, the above two would both become:
$STDERR->print(@data);
Assuming that print really did work as a true indirect object. This rule
generalizes to any function:
clone($obj @args); # $obj->clone(@args)
mogrify($trans[0] @stuff); # $trans[0]->mogrify(@stuff);
So, this allows us to use the current C form
without special parsing rules. Notice that this rule does I allow
you to do this:
do_stuff(@data);
and expect Perl to magically figure out that C<$data[0]> is an object
reference. That's just I. The first argument I be a
scalar without a trailing comma.
=head2 Why this is a needed
At first, this may seem like syntactic sugar. It's not, it's much more
than that.
In fact, this makes Perl 6 much more flexible and reduces the number of
core methods, without confusing the end user with inconsistent syntax.
In fact, methods such as C and C could leave core
altogether, instead being called on the objects:
$FILE = open(http "http://www.yahoo.com/"); # http->open
close($FILE);# $FILE->close
It should be obvious what the benefits of being able to do this are.
It makes the core syntax much more flexible, and reduces the need
to include simple translator prototypes. This makes B, much more realistic since
these prototypes no longer have to handle the special case of an
"optional first argument object". For example:
print($STDOUT @data) becomes $STDOUT->print(@data);
automatically via parsing, meaning that CORE::print can be a
prototypeable function.
=head3 Ambiguity: Bareword indirect object
The following ambiguity exists in Perl 5 which is neither solved nor
made worse by this RFC. However, it is worth addressing since we're
talking about indirect objects.
When the indirect object is a bareword, considerable ambiguity exists
which can actually be quite difficult to resolve cleanly:
$p = new Person name => $name, age => $age;
The above example is valid in Perl 5. However, it can be difficult to
read and maintain, and many people would promote disambiguating it in
one of the following ways:
$p = new Person (name => $name, age => $age);
$p = new {Person} name => $name, age => $ag
RFC 200 (v3) Objects: Revamp tie to support extensibility (Massive tie changes)
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects: Revamp tie to support extensibility (Massive tie changes)
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 7 Sep 2000
Last Modified: 29 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 200
Version: 3
Status: Frozen
Requires: RFC 159
=head1 ABSTRACT
C is really cool. Mostly. It has an amazing amount of power in
concept, but suffers from several limitations which this RFC attempts to
address.
=head1 DESCRIPTION
=head2 Overview
Many people have expressed problems with tie, including Larry [1].
C suffers from several limitations:
1. It is non-extensible; you are limited to using
functions that have been implemented with tie hooks
in them already.
2. Any additional functions require mixed calls to tied
and OO interfaces, defeating a chief goal: transparency.
3. It is slow. Very slow, in fact.
4. You can't easily integrate tie and operator overloading.
5. If defining tied and OO interfaces, you must define
duplicate functions or use typeglobs.
6. Some parts of the syntax are, well, kludgey
This RFC attempts to address all of these points with some changes to
syntax and implementation concepts. It interacts with the concept of
B, described in B, to provide a simple and
extensible framework.
=head2 New Concepts
This RFC proposes two key principles that will provide a more
general-purpose C framework:
1. Operator, data, and syntax overloading will be
done via the ALLCAPS methods described in B.
2. All functions can be overloaded via the C pragma.
In addition, the declaration of a tie statement is suggested to be
changed into a standard indirect object function:
$object = tie Tie::Class @array_to_tie;
The default Cing would be performed by C, which
would be a new method that properly "blessed" the tied variable and then
simply turned around and called the class's C method, similar to
how the builtin C works currently.
There are many changes, so let's go through them one at a time and then
revisit how they will all tie (ha-ha) together at the end.
=head2 Syntax Changes
=head3 Drop C builtin and replace with C
As mentioned above, this allows us to call C in a simple indirect
object form. This eliminates one more special-case function which
currently requires that quotes be placed around the class name. This
syntax should simply be modified to be called on the object it will be
tied to, since C is after all an object constructor.
=head3 Drop C
Thanks to the below syntax, differentiating between filehandles and
other scalars is no longer important. It would also be very difficult to
make this distinction, since in Perl 6 filehandles are intended to be
C<$scalars>.
=head3 Continue to do data handling through ALLCAPS methods
This will not change. C and C, along with other functions
described in B and below, will continue to do data handling.
In addition, these methods will be used for operator overloading as
well, providing a unified C and C environment.
=head3 Pass the original variable tied as an argument
Currently, C methods do not have access to the original variable
being tied. This means that currently values are destroyed altogether
when tied, basically.
Perl 6 C should receive the value being tied as the first real
argument:
sub ReadOnly::TIESCALAR {
my ($class, $original, @otherargs) = @_;
bless {
internals => \@otherargs,
value => $original,
}, $class
}
sub ReadOnly::FETCH { return $_[0]->{value} }
# and later:
my $x = 10;
tie $x, 'ReadOnly';
print $x; # still prints 10
The above example is shamelessly stolen from an email by Damian. :-)
However, I think it may be best to pass it by reference, since this
would allow you to derive both the name and value of the original
variable. But this RFC does not take a firm stand one way or the other
on this detail.
=head3 Add C method called by C
When called, C currently suffers the somewhat nasty problem of
not being able to automatically destroy inner references. This means if
you've mixed OO and Cd calls, you may not be able to destroy your
tied object as easily as you like. [2]
An C method should be added which is called when a tied variable
is untied. This solves the problem of C not being called when
you think it's going to be.
=head3 Ability to C arbitrary functions
Currently, C suffers from being non-extensible:
push @tied_array, $value;
sort { $a <=> $b } @tied_array;
The first one can be implemented as C by your tied array class,
but there is no way that you can transparently offer a custom C
routine. While Perl 5.6 finally has a fairly substantial collection of
C methods, it is easy to imagine that future functions will arise
which you want to C, but which support has not been added for yet.
Plus, if you want to support extra methods of your own, you m
RFC 265 (v3) Interface polymorphism considered lovely
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interface polymorphism considered lovely
=head1 VERSION
Maintainer: Piers Cawley <[EMAIL PROTECTED]>
Date: 20 Sep 2000
Last Modified: 29 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 265
Version: 3
Status: Frozen
=head1 ABSTRACT
Add a mechanism for declaring class interfaces with a further method
for declaring that a class implements said interface. There should be
(at least) runtime checking to ensure that a class actually *does*
implement said interface, with an option to have compile time checks
made.
=head1 NOTES ON FREEZE
Nothing has changed since version 2. There's still probably stuff that
could use working on, but the deadline looms like a big loomy thing,
so into the freezer it goes.
=head1 CHANGES
=over 4
=item Notes
I've tried to add [Note ...] lines in bits where I need some further
input to try and nail the RFC down.
=item More compile time errors
It's now a compile time error if an interface file tries to do
anything other than pre declare methods.
=item Added a reference to RFC 193 C.
=item Removed the 'too ugly to live' :must(Foo) suggestion.
I didn't like it, Damian didn't like it, and it was Damian's idea. So
it's gone.
=back
=head1 DISCUSSION
=over 4
=item *
Damian points out that the distinction between C and C don't need to be distinguished. I believe that, although
it may be the case that there's no need to make the distinction in the
internals of perl, the distinction is a useful mnemonic one for the
programmer, and (I think) separating the different meanings into
different pragmata potentially simplifies the implementation of both of
'em.
He also further points out that C isn't strictly
necessary. I counter that it may not be necessary, but it'd be a
simple pragma module to write and would again serve to help clarify
the programmers intent.
=back
=head1 DESCRIPTION
=head2 Rationale
To (mis)quote Damian Conway "Inheritance polymorphism proliferates
pretend classes".
The idea is that C will eventually give us some real
performance gains, so more folks will want to use it. But this leads
to a proliferation of 'ghost' base classes that are simply there to
provide a handle for C optimization.
So, I propose that we move such classes sideways and make them into
first class interfaces. By supporting interface polymorphism the way
is opened for adding more stricture in projects that *need* it, as
well as allowing for the possibility of compile time optimization for
classes that use the interface structure.
=head2 Syntax
My current thought is that an interface file would look something
like:
interface Fetcher;
sub fetch;
Note the new keyword, interface, this works just like package but with
the restriction that it can only contain subroutine declarations.
A Class that implements the interface would then look like:
package TrainedCat;
use strict 'implementation';
use strict;
use base 'Cat';
use interface 'Fetcher';
sub fetch {
my TrainedCat $self = shift;
my $thing = shift;
return $self->can_lift($thing) ? $thing : undef;
}
Note the C, this declaration implies that
interface conformance shall be checked at compile time. If the
C class doesn't implement the C interface in full
then compilation shall fail. Without this stricture constraint the
compiler shall throw a warning.
If an interface file contains anything but forward subroutine
declarations the compiler shall throw an error.
[NOTE: What about interface inheritance hierarchies, thoughts please]
Of course, Perl being Perl and all lovely and dynamic, there's a good
chance that some of the methods that implement the interface aren't
actually compiled up at the end of the compilation phase. Therefore we
have:
package LazyDog;
use strict 'implementation';
use interface 'Fetcher';
use deferred qw/fetch/;
...
sub AUTOLOAD {
...
*fetch=sub {...}; goto &fetch;
...
}
C informs the compiler that the method will be available
when it's needed, even if it isn't actually in the symbol table/class
hierarchy just yet.
In client code, lexicals that are typed into interfaces only require
that the objects assigned to them satisfy the interface. ie. They
don't care about an objects class, they just care what it can do. (If
only life were like that...)
use strict 'interfaces';
my Fetcher $x;
my Dog $spot;
my NetSnarfer $z;
my $method = 'fetch';
# Compile time stuff
$x = $z;# ok because $z can fetch
$x = $spot; # ok because $spot can fetch
$x->fetch();# ok because Fetcher->can('fetch');
$x->bark(); # not ok because ! Fetcher->can('bark');
# Runtime stuff
$x->$method(); # ok because Fetcher->can('fetch');
$method='bark';
$x->$method(); # runtime error because ! Fetcher->can('bark')
Without the C declaration, these errors get
demoted to compile time warnings. Of course, without the stricture any
RFC 335 (v2) Class Methods Introspection: what methods does this object support?
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Class Methods Introspection: what methods does this object support?
=head1 VERSION
Maintainer: Mark Summerfield <[EMAIL PROTECTED]>
Date: 28 Sep 2000
Last Modified: 29 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 335
Version: 2
Status: Frozen
=head1 NOTES ON FREEZE
In view of the lateness of my submission I've only had one response, from
Piers Cawley; we've exchanged several emails and Piers' suggestions and code
has been incorporated.
There are no issues to resolve.
This RFC does not depend on any other RFC.
=head1 ABSTRACT
This RFC proposes a new UNIVERSAL method which would be used thus:
my @method_names = $object->methods(); # OR MyClass->methods();
The C call would return the public methods of the C<$object> or
class; calling with the argument 'all' would return all the public methods
that the C<$object> or class could respond to.
=head1 DESCRIPTION
How can we tell which methods an object supports? If we know the names
of the methods we're interested in we can use
C<$object-Ecan('methodname')>. However if we don't know the possible names
then we're stuck. This RFC proposes a new UNIVERSAL method which would be used
thus:
@method_names = $object->methods(); # OR MyClass->methods();
@method_names = $object->methods('all'); # OR MyClass->methods('all');
The first example returns the public methods of the C<$object> or class
itself; the second example returns any public methods that the C<$object> or
class could respond to, i.e. all the methods of the class plus those of any
classes it inherits from.
The C method may I be able to determine definitively all the
methods that are available: firstly it is perfectly possible to define new
methods at runtime using C; secondly if the class has an C
method then the methods it supports may not be determinable. In the case of
classes that use C the string 'AUTOLOAD' would naturally be one of
the method names returned so at least the programmer would be aware that any
number of other methods may exist. Thus C would return the list of
methods known to be available to the object at the time that C is
called.
Piers Cawley suggested this:
"I would say that in an OO context there's a case for walking the @ISA tree to
find out all the methods that the class will respond to, say
C<$object->all_methods>, after all, in a complex class hierarchy there may be
classes that implement only one or two methods that are distinct from the
methods of their parent class."
I think that Piers extension is a valuable one, but propose that it should be
achieved by having an optional argument, 'all' to C rather than a
separate new method; this ensures the minimum addition to UNIVERSAL and also
leaves open the prospect of additional or different parameters being added in
future.
C could of course be over-ridden on a class-by-class basis; for
example, if your class supported fifty methods, but half of them were so
rarely needed that they were created on-the-fly in AUTOLOAD you could
return all their names if you override C and return the list of
names yourself. Furthermore as a method of UNIVERSAL C would not
collide with any existing or subsequent function of that name.
In terms of RFC 188 I would expect C to return public methods
only.
Why not simply use C to determine the class? Often knowing the
class is all that is necessary; however sometimes it is useful to know
what the possible methods are. Imagine we have a simulation system with
a core application that sends and receives signals to the objects it is
simulating (by calling their methods). Users may implement the objects
they want simulated by creating their own classes for each type of object.
One approach to this is to supply the user with a base class from which
they inherit. This has a disadvantage -- a given method is always called
in response to a given event because each event in the simulator maps to a
method in the base class. Sometimes we want to "wire up" the simulated
object so that on a particular run event A calls method A, but on another
run event A calls method B. Hardwiring this isn't a problem, but what if
we want to provide the user with this choice interactively -- well, if we
don't know what methods the class supports in the first place we cannot
give the user a list to choose from. The solution is to be able to
introspect on the class they've chosen and show them the list of methods
available; they can then choose which to wire up to which events in the
simulator. I am sure that there are other situations where object
introspection would be useful, for example a class browser.
=head1 IMPLEMENTATION
I think this needs to be implemented in Perl itself so that it can avoid
private methods and can be implemented efficiently, but here's some code which
provides a combined implementation and example:
#!/usr/bin/perl -w
# filename: test.pl
#
RE: RFC 265 (v3) Interface polymorphism considered lovely
> Java is one language that springs to mind that uses interface > polymorphism. Don't let this put you off -- if we must steal something > from Java let's steal something good. Interface inheritance is probably the least dignified thing to steal from Java. If we have true multiple inheritance, interfaces don't apply. (As a C++ programmer, I've always had to consider the interface OOP of Java and Delphi as flawed and incomplete. By golly, a dog CAN be a furred animal AND a four legger without having to define one or the other entirely in each class where I want either a furred animal and a four legger.) We already have true multiple inheritance. Therefore, interface OOP is unnecessary. However, some syntactic sugar to accomplish what you are looking for might be in order. Maybe implements() or isa()? (Is a())
Re: RFC 319 (v1) Transparently integrate C
On 26 Sep 2000, Perl6 RFC Librarian wrote: > So, for example: > >package var; # main variable class > ># all the main Perl internal methods are defined, such ># as TIESCALAR, TIEARRAY, STORE, FETCH, etc > >package int; >use base 'var'; > ># ideas for RFC 303 >use optimize storage => 16, # how much space > growable => 1, # can we grow? > growsize => 8, # how much to grow by > integer => 1,# support ints > string => undef, # but not strings > float => undef, # or floats > promote => 'bigint'; # promote to class > # when outgrow > ># TIESCALAR, STORE, etc need not be redefined, since ># they could simply inherit from var's, but perhaps ># we could define special math ops per RFC 159. > > In this example, we've used the C class to define several key > optimizations for Perl to use. Since C is the grandfather class of > all variables, its C and C methods can be used, which > actually do the internals of storing values and using the hints set by > the C pragma. The suggested C< use optimize > pragma is starting to grow many heads. C< use less > was such a simple little pragma, a general direction for the interpreter to take. Here it seems that the optimizations apply to the C< package int; > only. Are we suggesting that optimizations should be localized? Can I C< use optimize 'memory' > in one package and C< use optimize 'CPU' > in another? Do optimizations have block scope? I like C< use less >. I trust that perl6 will DWIM. Alan Gutierrez
Re: RFC 319 (v1) Transparently integrate C
Alan Gutierrez wrote: > > The suggested C< use optimize > pragma is starting to grow many heads. > C< use less > was such a simple little pragma, a general direction for > the interpreter to take. Here it seems that the optimizations apply to > the C< package int; > only. Are we suggesting that optimizations should > be localized? Can I C< use optimize 'memory' > in one package and C< use > optimize 'CPU' > in another? Do optimizations have block scope? > > I like C< use less >. I trust that perl6 will DWIM. It may be the case that both need to exist in this case. I would imagine that the C pragma should be able to give you really minute control over this stuff. And yes, I was suggesting these changed be localizable (at least some of them). C might be good for general C stuff, as you note. -Nate
