Re: RFC 161 (v4) Everything in Perl becomes an object.
On Wed, Sep 27, 2000 at 05:25:28AM -, Perl6 RFC Librarian wrote: 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. How might I persuade you to reconsider? I was kind of hoping that this one would get withdrawn as well. Ok, no fair sniping after a freeze. You were warned. It's called email, people! Use it. Jeez... Matt
Re: RFC 161 (v4) Everything in Perl becomes an object.
On Wed, Sep 27, 2000 at 12:16:36PM -0700, Matt Youell wrote: I open to hearing your reasons. The biggest reason it wasn't withdrawn is because someone said "hey don't do that, here's why". So give me a "why" already... It doesn't feel right to me. It doesn't feel Perlish. That's it? Matt
Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors
Damian Conway wrote: * invoke some other hierarchy of automagic methods (REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or REINCARNATE
Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
Right now, the default behavior of perl is that un-initialized variables
are automatically undef. It would be weird to have to do explicit
assignment of an variable to say so.
You're right. And as another post mentioned, it's too much "magic". But It's
hard to come up with a comfortable syntax for doing both.
In C++, you've got two syntaxes for a reason: Objects either live on the
stack or the heap. So each syntax has a direct under-the-hood correlation to
the different ways of storing an object. I Perl, we don't really care where
the object gets stored so it's not as natural to make the distinction.
Perhaps the shift-on-the-fly usage could explicitly use a typeglob syntax
and declare it to be associated with Dog?
my Dog *spot;
if ($age 12) {
$spot = new Doberman();
} else {
$spot = new Corgi();
}
Matt
Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
mainstream OO languages go). It looks like Dog could be a type of String
subclass.
That was my first thought as well. Besides, I'd rather type:
my Dog $spot("Spot");
Which says everything that needs to be said without any repetition, and it's
fairly intuitive.
As with the above, the problem you are trying to solve is long type-names
(which is a bazzar thing to find in perl anyway). I just think that there
are better ways of skinning that cat.
I think the main idea here is this: being allowed to say what you mean
without repeating yourself.
Matt
Re: RFC 161 (v2) OO Integration/Migration Path
I've read over 161 again and I'm starting to see areas where I can clarify things greatly. I apologize for the confusion. I'll make mods to the RFC in the near future, after I get more feedback from you all. Here are my goals as they probably should have been stated in the RFC: - Concentrate responsibility closer to the basic data structures (currently scalar, list, and hash). - Allow customization of these structures by the user, though inheritance. - Reduce or eliminate the need for new keywords in Perl itself, since the basic data structures can be extended as needed. - Maintain a migration path for Perl 5 (so I can have all of this without touching my existing code). I shudder to think of something that prevents simple variable accesses and instead requires verbose method calls. That doesn't seem to be making anything easy. Ditto. Accessing data doesn't change. I'm not suggesting accessors be added to scalars. Rather, I'm suggesting that scalars be responsible for knowing their type, rather than Perl being responsible for that. Methods like 'asInt()' are intended to act as a switch that gets flipped so the scalar knows what type it is supposed to be. Optionally, they could also act as a cast mechanism when used as an rvalue. An overloadable cast mechanism at that. Do you mean that when we write: my int $intVal = 0; it gets turned into OO stuff? Or do you mean that we won't be writing my int $intVal = 0; any more? I don't like the latter option. It would seem to require more typing to allow something that a minority of people will use. Originally I was trying to avoid explicit typing through new keywords, like 'int'. So the latter option would have been the case. But after Nathan Wiger's reply to my RFC, I realized that either syntax would work. Under one scenario, 'int', as in your example, would simply be the name of a factory function, so that: my int $intVal = 0; could be equivalent to: my $intVal = Scalar-int(0); And with no more typing required than before. Matt
