RFC 161 (v4) Everything in Perl becomes an object.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Everything in Perl becomes an object.
=head1 VERSION
Maintainer: Matt Youell <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Last Modified: 26 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 161
Version: 4
Status: Frozen
=head1 ABSTRACT
Everything in Perl becomes an object, out of sight, but within easy reach.
Perl stays Perlish. Syntax remains fundamentally the same; Perl 5 code
migrates well.
Previous versions of this RFC were entitled "OO Integration/Migration Path".
=head1 NOTES ON FREEZE
Not an awful lot was said once this RFC was condensed down to "Everything
becomes an object". I believe some implementation and conceptual hurdles
exist which have discouraged more serious discussion. At the suggestion of
others I've opted to freeze rather than withdraw.
=head1 DESCRIPTION
=head2 Goals
1. Provide a more complete mechanism for extending the language.
2. Organize responsibilities closer to the corresponding data structures.
3. Maintain a compatibility bridge to Perl 5.
=head2 Proposal
Everything in Perl becomes an object, using (mostly) existing object-syntax.
The built-in types $scalar, @list, and %hash become the extensible base
classes Scalar, List, and Hash. New built-in data types (such as int, bool,
string, etc.) are derived from Scalar. Regular "vanilla" $scalars don't go
away, they are simply considered to be instances of Scalar. And like any
$scalar, they still Do The Right Thing.
=head2 Syntax
"my Dog $spot" works under this model.
Where a class is not provided, a default is deduced from context ($, @, %).
For example:
my $foo = "foo";
is equivalent to:
my Scalar $foo = new Scalar("foo"); # (Or similar. This syntax is
currently in discussion.)
Methods would be called as they are for any object:
$noun->verb();
or, indirectly:
verb $noun;
=head2 Extensibility
By allowing Perl's built-in types to be extended, programmers can retain
Perl's simple syntax while better fitting their particular problem domain.
All without polluting the core language.
For example, there has been discussion of adding transaction support to
Perl. Rather than adding such support into the language directly, it could
be added as a subclass of Scalar. This might work like so:
use Transactions::Scalar; # This replaces the default scalar with a derived
class. A detail needing exploration.
my $firstName = "Bob"; # AKA: my Transactions::Scalar $firstName = new
Transactions::Scalar("Bob");
# ... (transaction happens) ...
commit $firstName; # or rollback $firstName
Or, say that you wanted to override built-in behavior. Perhaps you want
'ord' to return numeric EBCDIC values. You can create your own 'ord' routine
in your derived class and have it do that very thing.
=head2 Conclusion
This approach provides a means for adding functionality while leaving the
basic language structure alone. It doesn't interfere with improvements
happening elsewhere in the language, and it leaves a clean migration path
for Perl 5 code.
=head1 IMPLEMENTATION
This RFC tries to present a user-interface view of how this feature would
work. Other RFCs cover the specific nuts & bolts approaches that are
possible.
=head1 REFERENCES
RFC 137: Overview: Perl OO should I be fundamentally changed.
(specifically the EXECUTIVE SUMMARY)
RFC 159: True Polymorphic Objects
http://www.youell.com/matt/perlstring/ - A C++ string class that emulates
Perl's scalar manipulation tools. Bears some similarity to the Scalar object
described here.
Re: RFC 279 (v1) my() syntax extensions and attribute declarations
On 24 Sep 2000, Perl6 RFC Librarian wrote:
I still hope that it doesn't get as complicated as all this. I know
there are arguments out there for specifying integer size and signedness
but I can't imagine that adding this stuff is a good thing.
> Note that multiple types cannot be specified on the same line. To
> declare variables of multiple types, you must use separate statements:
>
>my int ($x, $y, $z) :64bit;
>my string ($firstname, $lastname :long);
Not so bad if I don't have to worry about 64bit or long. I'd rather not
worry about integer versus string, but I assume there are some
performance gains in doing so.
>$a[0] :32bit = get_val; # 32-bit
>$r->{name} :private = "Nate"; # privatize single value
>$s->{VAL} :laccess('data') = ""; # lvalue autoaccessor
Here I'd prefer to see private and laccess as functions.
private $r->{name} = 'Nate';
laccess $s->{VAL} = '';
And as far as the :shared modifier goes I much prefer the our keyword.
Alan Gutierrez
Re: RFC 319 (v1) Transparently integrate C
> I'm kind of curious to know what you think would happen with the
> following. I've commented where I'm confident...
>
> interface Number;
> sub TIESCALAR;
> sub STORE;
> sub FETCH;
>
> package integer implements Number; # I really like this notation
Tangentially, yes, it is nice to read, but it prevents multiple
interface specifications. "use interface" is more consistent.
> sub TIESCALAR {...};
> sub STORE {...};
> sub FETCH {...};
>
> my Number $i; # Number is an interface, so just an assertion
> my integer $n; # integer->TIESCALAR($n);
> my non_tied $object;# Just an assertion
> defined($n);# Should be false
Yes. The only potential gotcha is if the user decides to do something
Really Evil and stores a value as part of their TIESCALAR method. Then
$n->FETCH will return that value and defined($n) will be true.
However, this is not the purpose of tie, and I think an appropriate
response is: Don't Do That. I agree with both you and Damian that TIE*
should be called on declaration for consistency. If a person doesn't
know how to use tie, well, that's not our problem. ;-)
> $n = 5;
> $i = $n;
> $n = 10;
> print $i;
> $i = $object; # Assertion fails
Assuming you've set up your C restrictions appropriately,
then yes. The key is really what 'non_tied' is setup as. If this is a
builtin type that optimizes itself to be a string object, then yes it
will fail. However, if 'non_tied' is just a synonym for 'float' (for
some odd reason) then the last line will be ok.
> >my int @b :64bit; # again, just an assertion
>
> Asserting what? That's not valid syntax at the moment.
But it will be. :-) See RFC 279.
> >@c = @b;# empty list passed still
> >@b = (1,2); # int->TIEARRAY(@a, '64bit'); @b->CLEAR(...);
>
> Hmm... I think this is somewhat ugly. Assuming that you want
> C to imply C then tying the
> entire array seems a bit weird.
Not necessarily. The key is: *how* would you implement the assertion
check?
If you use tie, then your int class STORE method can do something like
this:
package int;
use base 'var';
# take defaults from var class
STORE {
if ( self->isa($_[1]) ) {
SUPER->STORE($_[0], $_[1]); # internally store
} else {
die "Bad data $_[1]" if ( $under_strict_types );
}
}
Now, there's a difference between _could_ do this and _must_ do this.
The idea here is that you could do this, and users wouldn't see any
difference between your custom types and builtin types.
> Er... You seem to be implying here that *all* classes should have TIE
> methods. Which is not good.
No, I wasn't trying to imply that, I'll clarify this point. TIE methods
are still completely optional.
> Err... Specifying which classes implement an interface in the
> interface specification is Wrong Wrong Wrong.
Yes, you're right, and it's way outside of this scope of this RFC,
actually. Your idea:
> my Pet $spot : isa(any(qw/Dog Cat/)) = new Camel; # oops!
is much better for this application.
> Can I just point out that nobody has yet proposed that you can attach
> attributes to a package?
Didn't Damian propose C already? ;-)
> I'm not entirely sure what you're driving at here. I thought you were
> arguing that *all* packages that created objects would use tie magic,
> in which case the new attribute becomes unnecessary. And if you're not
> proposing that then :tie is too general in the cases where the module
> can only tie to specific variable types. I think you get better
> granularity with interfaces, which are way more general than a special
> new attribute.
No, let me back up a little. The idea is to make it so that tied
interfaces - which are really different beasts from OO interfaces
altogether because of their purpose - should be more closely integrated
into Perl 6. This would allow you to create custom, optimized,
strongly-typed variables that would function just like builtins:
my Matrix @a = ([1,2,3], [4,5,6]);
my NISMap %map :passwd = read_passwd_file();
my Apache::Session %session :transaction;
However, this is not to overshadow OO interfaces, which are needed for
functional methods, as you note.
The :tie attribute is a poorly chosen name. The original name was
:implicit, and was going to be attached to the TIE subs:
package Demo;
sub TIESCALAR : implicit { ... }
sub TIEHASH : implicit { ... }
sub TIEARRAY { ... }
So in this example, a user can say:
my Demo $x;
my Demo %x;
my Demo @x; # TIEARRAY not called
However, after thinking about this, I decided this was not a worthwhile
distinction. How often would you want this behavior? So I decided to
attach the attribute to the package:
package Demo : implicit;
But that really didn't connote what was going on. So I changed it to:
package Demo : autotie;
But then decided the 'auto' was redundant. However, the more I think
about it it a
Re: RFC 319 (v1) Transparently integrate C
> Somewhat to my own surprise, I really like this RFC. Thanks :-) > My only disagreement is that I think it's a mistake to defer the call > to TIEWHATEVER until the first access. It ought to be done when > the typed variable is declared, so that it's easy to determine where > a variable is tied. Yeah, that's fine. I was trying to keep inline with RFC 218, because I thought it would be weird for this: my Pet $spot;# tied my Dog $x; # not print "ok" unless (defined $spot or defined $x); to return true and not print "ok". But I guess you can easily check with tied() too, and it makes more sense to just tie it on declaration (my original inclination). > There is also the issue of how one passes multiple > arguments to set up the tied variable in the first place. > Something like this perhaps: > > my Tieable $var : tie(@args) = $init_val; Excellent! > Also, I didn't see any reference to the fact that RFC 218 will > have to change to "...just an assertion, unless the package autoties, > in which case it's no longer an assertion". Yes, I believe Piers brought something like that up too, I'll go answer his thread as well... -Nate
Re: RFC 319 (v1) Transparently integrate C
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Transparently integrate C
On the whole I think I'm liking this. But it needs work.
>my packed $a; # just an assertion, RFC 218
>$a = get_binary;# packed->TIESCALAR($a); $a->STORE(..);
I'm not sure there's any reason to delay the tie; It kind of depends
on what happens to stuff like 'defined($a)'. RFC 218 was brought
forward because I didn't want magic to be happening in cases where
C was using a Foo that was a superclass, and there was no
mechanism for knowing that at the time.
I'm kind of curious to know what you think would happen with the
following. I've commented where I'm confident...
interface Number;
sub TIESCALAR;
sub STORE;
sub FETCH;
package integer implements Number; # I really like this notation
sub TIESCALAR {...};
sub STORE {...};
sub FETCH {...};
my Number $i; # Number is an interface, so just an assertion
my integer $n; # integer->TIESCALAR($n);
my non_tied $object;# Just an assertion
defined($n);# Should be false
$n = 5;
$i = $n;
$n = 10;
print $i;
$i = $object; # Assertion fails
>$a = more_data; # $a->STORE(...);
>$a++; # $a->STORE($a->PLUS(1));
>undef $a; # $a->DESTROY;
>
>my int @b :64bit; # again, just an assertion
Asserting what? That's not valid syntax at the moment.
>@c = @b;# empty list passed still
>@b = (1,2); # int->TIEARRAY(@a, '64bit'); @b->CLEAR(...);
>...
Hmm... I think this is somewhat ugly. Assuming that you want
C to imply C then tying the
entire array seems a bit weird.
> Note that the C methods will only be called if they exist, just
> like currently. If a given C method does not exist, then the
> appropriate error should be spit out:
>
>my Pet @spot = ("fluffy");
>Can't locate method "TIEARRAY" via package "Pet"
>
> In this case, the package C has declared that it can't handle
> arrays, which is just fine.
Er... You seem to be implying here that *all* classes should have TIE
methods. Which is not good. It's especially not good in cases where
the class is actually an interface. Hmm... maybe we should have the tie
behaviour only happen if the package is declared as implementing an
appropriate 'Tie::Foo' interface:
package integer implements Tie::Scalar;
Note that this would imply that the Tie::Foo modules in the standard
library become interfaces, but I'm not sure that that would be any
great loss...
> =head2 Optimization and Inheritance
>
> One of the main goals behind doing something like this is being able to
> create custom variable types that can take advantage of optimizations,
> and having these variables walk and talk like builtins.
>
> For this reason, it is further proposed that all variable types be
> handled through basic method inheritance in Perl 6. Essentially,
> everything becomes an object and is fully overrideable and redefineable.
> So, for example:
Whoa, now you're stretching.
> [...]
> =head2 Type checking
>
> Nat's upcoming RFC on type checking will propose a C
> pragma. Type checking would be trivial to implement by combining aspects
> of this RFC with the C concept:
>
>package Pet : interface; # RFC 265
>use optimize types => ['Dog', 'Cat'];
>
> With this declaration, Perl is now told that anything of type C can
> be either a C or a C.
Err... Specifying which classes implement an interface in the
interface specification is Wrong Wrong Wrong.
> This means that in your main code:
>
>use strict 'types';
>my Pet $spot = new Camel; # oops!
>
> The second line would raise a syntax error.
If your client code wants to insist that the only pets it's interested
in are Dogs or Cats then you should make that assertion somewhere.
You certainly shouldn't assert it in the interface declaration.
Check out the
my Pet $spot : isa(any(qw/Dog Cat/)) = new Camel; # oops!
style that I proposed elsewhere.
> =head2 The C<:tie> attribute
>
> Making C this seamless may scare some people. In this case, we may
> wish to add an C<:tie> attribute that can be specified on the
> C:
>
>package Pet : tie; # will be auto-tied
Can I just point out that nobody has yet proposed that you can attach
attributes to a package?
>
> Placing this on the package, and not individual subs, makes more sense
> because it dictates how all the package's methods interact.
>
> The idea here is that by fully integrating these concepts, a separate
> C function will no longer be necessary and will instead be replaced
> by a simple C<:tie> package attribute (or no attribute at all).
I'm not entirely sure what you're driving at here. I thought you were
arguing that *all* packages that created objects would use tie magic,
in which case the new attribute beco
Re: RFC 307 (v1) PRAYER - what gets said when you C something
Simon Cozens <[EMAIL PROTECTED]> writes: > On Tue, Sep 26, 2000 at 07:20:08AM +1100, Damian Conway wrote: > > RFC 189 covers this. > > So it does! Cool, I can withdraw mine *and* get the warm fuzzy feeling that > comes from like-thinking-of-great-minds. > > RFC 307 is withdrawn! I do like the C special subroutine as a way of sidestepping the naming arguments that sprang up with RFC 189 though. -- Piers
Re: RFC 307 (v1) PRAYER - what gets said when you C something
On Tue, Sep 26, 2000 at 07:20:08AM +1100, Damian Conway wrote: > RFC 189 covers this. So it does! Cool, I can withdraw mine *and* get the warm fuzzy feeling that comes from like-thinking-of-great-minds. RFC 307 is withdrawn! -- How do I type "for i in *.dvi do xdvi i done" in a GUI? (Discussion in comp.os.linux.misc on the intuitiveness of interfaces.)
Re: RFC 319 (v1) Transparently integrate C
Somewhat to my own surprise, I really like this RFC. My only disagreement is that I think it's a mistake to defer the call to TIEWHATEVER until the first access. It ought to be done when the typed variable is declared, so that it's easy to determine where a variable is tied. There is also the issue of how one passes multiple arguments to set up the tied variable in the first place. Something like this perhaps: my Tieable $var : tie(@args) = $init_val; Also, I didn't see any reference to the fact that RFC 218 will have to change to "...just an assertion, unless the package autoties, in which case it's no longer an assertion". Damian
