Michael Fowler [EMAIL PROTECTED] writes:
On Mon, Sep 04, 2000 at 10:34:37AM +0100, Piers Cawley wrote:
Well then, that's one nay vote. :)
Make that two.
Three. But I think Michael already knew about mine and forgot to count
it.
Heh, I am not counting votes. That was
Well, unless there are any wildly different points someone hasn't mentioned
until now, I'm going to freeze this RFC as it is (with a few minor tweaks).
Various alternate syntaxes have been suggested, but I still rather like
mine. Let Larry do with it what he will. Hopefully he can take
Michael Fowler [EMAIL PROTECTED] writes:
On Fri, Sep 01, 2000 at 10:22:49AM +0100, Piers Cawley wrote:
And then there's:
- Makes factory methods impossible.
my Dog $spot;
my $pub = $spot-procreate;
Sure looks like a factory method to me. Just because you don't get to
Michael Fowler [EMAIL PROTECTED] writes:
On Sun, Sep 03, 2000 at 12:42:52PM +0200, Bart Lateur wrote:
But now you're throwing away the kid with the bathwater.
my Dog $spot;
initially was syntax invented so that $spot was marked as only been ably
to reference a Dog, with as a
Nathan Wiger [EMAIL PROTECTED] writes:
Piers Cawley wrote:
First off, I think everyone is reading this RFC with the wrong mindset,
forgetting the concept of embedded objects in Perl 6.
Ah, that dumb idea again.
Well, if you disagree with this idea, you probably won't agree with
Damian Conway [EMAIL PROTECTED] writes:
But I agree that anything beyond that is simply horrible.
You'll only drive more people *away* from OO, because it
generates so horribly inefficient code. If you want a
constructor called, than FGS *call* a constructor. Maybe you
Michael Fowler [EMAIL PROTECTED] writes:
On Fri, Sep 01, 2000 at 05:23:27PM +0200, Slaven Rezic wrote:
Often, there is the case that "my" is used before actually assigning a
value to it. For example:
my Foo $foo;
if ($cond1) {
$foo = new Foo 1, 2, 3;
} else {
On Fri, 1 Sep 2000 11:59:15 -0800, Michael Fowler wrote:
my Dog $spot;
if ($input eq 'Collie') {
$spot = Collie-new;
} elsif ($input eq 'Dalmation') {
$spot = Dalmation-new;
}
Becuase we're creating two objects when we really only want one.
Yes. That my Dog $spot
On Sun, Sep 03, 2000 at 12:42:52PM +0200, Bart Lateur wrote:
But now you're throwing away the kid with the bathwater.
my Dog $spot;
initially was syntax invented so that $spot was marked as only been ably
to reference a Dog, with as a result that code internally could be
optimized,
On Sat, 2 Sep 2000, Nick Ing-Simmons wrote:
Damian Conway [EMAIL PROTECTED] writes:
But I agree that anything beyond that is simply horrible. You'll only
drive more people *away* from OO, because it generates so horribly
inefficient code. If you want a constructor called, than
On Fri, Sep 01, 2000 at 12:20:34PM +0100, Hildo Biersma wrote:
Michael Fowler wrote:
On Fri, Sep 01, 2000 at 08:31:17AM +0100, Hildo Biersma wrote:
My previous concerns have not been adressed:
- There may not be a default constructor
If there is no implicit constructor method
On Fri, Sep 01, 2000 at 05:23:27PM +0200, Slaven Rezic wrote:
Often, there is the case that "my" is used before actually assigning a
value to it. For example:
my Foo $foo;
if ($cond1) {
$foo = new Foo 1, 2, 3;
} else {
$foo = new Foo 2, 4, 6;
}
If we have
On Fri, Sep 01, 2000 at 11:41:47AM -0700, David E. Wheeler wrote:
Michael Fowler wrote:
my Dog $spot; # $spot is now a blessed Dog object
$spot-name("Fido");# $spot-{'name'} eq "Fido"
print ref $spot;# yes, "Dog"
$spot = new Dalmation; #
On Fri, Sep 01, 2000 at 10:58:36AM -0800, Michael Fowler wrote:
my $spot isa(Dog);
This should be my $spot : isa(Dog);
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
On Fri, Sep 01, 2000 at 09:09:15AM -0700, Nathan Wiger wrote:
First off, I think everyone is reading this RFC with the wrong mindset,
my Dog $spot;
print ref $spot;# 'Dog'
$spot = new Dalmation;
No reason this wouldn't still work. The term 'constructor' here is
misleading.
Michael Fowler wrote:
On Fri, Sep 01, 2000 at 11:41:47AM -0700, David E. Wheeler wrote:
Michael Fowler wrote:
my Dog $spot; # $spot is now a blessed Dog object
$spot-name("Fido");# $spot-{'name'} eq "Fido"
print ref $spot;# yes, "Dog"
On Fri, Sep 01, 2000 at 12:35:24PM -0700, David E. Wheeler wrote:
Well then, that makes this example rather wasteful, doesn't it?
It wasn't an example of how my Dog $spot should be used. I was explaining
to Nate what his code was doing.
my Dog $spot;
if ($input eq 'Collie') {
On Fri, Sep 01, 2000 at 10:22:49AM +0100, Piers Cawley wrote:
And then there's:
- Makes factory methods impossible.
my Dog $spot;
my $pub = $spot-procreate;
Sure looks like a factory method to me. Just because you don't get to say
my Dog $pup for some optimization doesn't mean
Bart Lateur wrote:
First: I don't like the idea of some user supplied code being called
whenever you declare a new variable, *unless* the author of the class
created a sub *especially written* for this purpose.
Exactly. Even then, the arguments must match.
So, if Dog::new() takes one
Michael Fowler wrote:
On Fri, Sep 01, 2000 at 08:31:17AM +0100, Hildo Biersma wrote:
My previous concerns have not been adressed:
- There may not be a default constructor
If there is no implicit constructor method defined by the class, and the my
Dog $spot syntax is used, a fatal
Often, there is the case that "my" is used before actually assigning a
value to it. For example:
my Foo $foo;
if ($cond1) {
$foo = new Foo 1, 2, 3;
} else {
$foo = new Foo 2, 4, 6;
}
If we have implicit constructors, will this cause unnecessary
overhead, that is,
Nathan Wiger [EMAIL PROTECTED] writes:
First off, I think everyone is reading this RFC with the wrong mindset,
forgetting the concept of embedded objects in Perl 6.
Ah, that dumb idea again.
I believe the idea would be that CREATE is a *fundamental* method, like
DESTROY, that would do
Piers Cawley wrote:
First off, I think everyone is reading this RFC with the wrong mindset,
forgetting the concept of embedded objects in Perl 6.
Ah, that dumb idea again.
Well, if you disagree with this idea, you probably won't agree with much
else I have to say on this subject. Just
Hildo Biersma [EMAIL PROTECTED] writes:
Perl6 RFC Librarian wrote:
=head1 DESCRIPTION
What is currently an optimization for pseudo-hashes:
my Dog $spot = Dog-new();
should be replaced with:
my Dog $spot;
which calls an implicit constructor (discussed further
On 01 Sep 2000 10:22:49 +0100, Piers Cawley wrote:
My previous concerns have not been adressed:
- There may not be a default constructor
- This makes creations of Singleton classes impossible
- There is a good reason to created typed, but undef, references
and fill them in later.
And
But I agree that anything beyond that is simply horrible. You'll only
drive more people *away* from OO, because it generates so horribly
inefficient code. If you want a constructor called, than FGS *call* a
constructor. Maybe you can reduce the syntax necessary to do that, but
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
my Dog $spot should call a constructor implicitly
=head1 VERSION
Maintainer: Michael Fowler [EMAIL PROTECTED]
Date: 29 August 2000
Last Modified: 31 August 2000
Mailing List: [EMAIL
On Thu, Aug 31, 2000 at 09:45:52PM -0600, Tom Christiansen wrote:
Well, remember that BEGIN{} blocks are just subs too, with an optional
'sub'.
Not exactly. They are not callable, as they disappear immediately.
More importantly, they have no @_, and things like pop and shift
act upon
Besides, what would be the alternative, BEGIN{} - like blocks?
Such blocks are put forth as an alternative:
Well, remember that BEGIN{} blocks are just subs too, with an optional
'sub'.
But that aside, I don't think a block is what we want to connote. A
block implies "this is evaluated
Well, remember that BEGIN{} blocks are just subs too, with an optional
'sub'.
Not exactly. They are not callable, as they disappear immediately.
More importantly, they have no @_, and things like pop and shift
act upon @ARGV from within them.
The compilerish chapter of the Camel calls them
On Thu, Aug 31, 2000 at 07:56:24PM -0700, Nathan Wiger wrote:
So the object would be left undefined? That means this code:
No, not at all. Remember, everything's going to inherit from CORE, at
the very least, which would have to provide a CREATE method which just
instantiates a simple
First off, nice additions to the RFC.
Listed below are constructor alternatives. If a sub is chosen (as in sub
PREPARE {}) it will suffer from the disadvantage of potentially causing
problems with current Perl modules.
I don't really think this is a valid concern. We can have p52p6 warn
On Thu, Aug 31, 2000 at 05:15:34PM -0700, Nathan Wiger wrote:
First off, nice additions to the RFC.
Thanks. :)
Listed below are constructor alternatives. If a sub is chosen (as in sub
PREPARE {}) it will suffer from the disadvantage of potentially causing
problems with current Perl
33 matches
Mail list logo
