Piers Cawley wrote:
>
> Well, you keep advancing this idea which has, as far as I can tell, no
> upside apart from the reduction in keystrokes required to instantiate
> an object. And in doing that you remove useful functionality from a
> bunch of other cases.
>
> No wonder we're down on the ide
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
On Mon, Sep 04, 2000 at 10:25:37AM +0100, Piers Cawley wrote:
> Maybe a compromise along the lines of:
>
>my Dog $spot = LIST; # $spot = Dog->new(LIST)
>my Dog $patches; # $patches is undefined but we assert that
> # it'll be a Dog. (Whether you can do
>
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 somethin
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 simply me acknowledging his dislike
for the
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;
> >
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.
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
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 Do
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 d
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
> opti
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.
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 constructo
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. Mayb
> > 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 th
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') {
>
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;#
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 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
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;
> }
>
> I
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 construc
On Fri, Sep 01, 2000 at 11:58:20AM +0200, 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.
And that's what the RFC states. If th
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
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; # now $spot is a Dalmation object
Yes, but the Dalmation $spot will *
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
> misleadi
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.
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
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,
First off, I think everyone is reading this RFC with the wrong mindset,
forgetting the concept of embedded objects in Perl 6.
I believe the idea would be that CREATE is a *fundamental* method, like
DESTROY, that would do basic declaration, creation, allocation, etc. So:
my Dog $spot;
print
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 fat
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 a
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.
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 constr
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 exception is raised. The RFC ment
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 in the IMPLEMENTATION
> section). The opt
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 up
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 simp
>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 bl
> > 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
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
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 11:48:51PM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> my Dog $spot should call a constructor implicitly
Look at me, replying to my own RFC, how tacky. :)
> If the multi-argument form of the constructor were to be adopted this would
> have to change. Dog->$M
42 matches
Mail list logo
