Kenneth Lee wrote:
>
> > Once a hash has been C-ized, the only way to extend its set of
> > entries is via another call to C:
> >
> > sub new {
> > my ($class, %self) = @_;
> > bless private \%self, $class;
> > private $self{seed} = rand;
Uri Guttman <[EMAIL PROTECTED]> writes:
> > "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>
> >> many systems allow for a global/local startup file for various
> >> reasons. i see a potential use of this in perl but i don't see the
> >> specific use yet. build it they will use i
> Once a hash has been C-ized, the only way to extend its set of
> entries is via another call to C:
>
> sub new {
> my ($class, %self) = @_;
> bless private \%self, $class;
> private $self{seed} = rand; # okay
> $self{se
> package Derived;
> use base 'Base';
>
> sub new {
> my ($class, $derdatum, @basedata) = @_;
> my $self = $class->SUPER::new(@basedata);
> private $self->{data} = $derdata;
On 9/2/00 12:16 AM, John Tobey wrote:
> Every base's SETUP gets the same argument list? That seems highly
> undesirable from an OO-purity standpoint. Or do you have a syntax for
> member initializer lists in store for us?
I've been thinking about this too. I want some sort of decision to
save
On Fri, Sep 01, 2000 at 08:59:10PM -, Perl6 RFC Librarian wrote:
> =head1 ABSTRACT
>
> This RFC proposes a new special method called C that is
> invoked automagically whenever an object is created. Furthermore,
> it proposes that both C and C methods should
> be invoked hierarchically in all
On Fri, 01 Sep 2000, Dan Sugalski wrote:
> I'm not sure. They're there mainly for guaranteed unfiltered access to the
> variable's guts, and I'm not sure what things will need that.
I use direct, raw access in prototyping when dipping back into C for
"heavy" data manipulations - bit stream analy
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> many systems allow for a global/local startup file for various
>> reasons. i see a potential use of this in perl but i don't see the
>> specific use yet. build it they will use it.
TC> But Perl is not an interactive shell! Ca
> =head2 Hierarchical C calls
>
> It is proposed that when an object is blessed, I of the C methods
> in any of its base classes are also called, and passed the argument list
> appended to the invocation of C. C methods would be called
> in depth-first, left-most order (i.e. ancestral C methods w
Can't quite run perl yet.
http://www.tomshardware.com/cpu/00q3/000901/index.html
> What happens on reblessing?
An excellent question, and one that has been exercising my mind for
some time now.
I have come to the conclusion that a reblessing must either:
* invoke the old class's DESTROY(s) and then invoke the
new class's SETUP(s), or
* invoke s
>What I am thinking of is a file that, if present and sane (i.e. read-only
>root), would be involked by the interpreter just before the users script was
>parsed. Looking at your example of things in the config file, well some of
>those are the things I would like to be able to get at in the new ve
>That's a fine answer, but a completely different concern.
Sorry, you are correct. I looked up the RFC (there are getting to be so many
I cannot trust memory any more).
What I am thinking of is a file that, if present and sane (i.e. read-only
root), would be involked by the interpreter just bef
>Well, it only does this if it's not something like 'split', then!
Yes, it does "do it" with split. split is defined to do what it
does, how it does it. *This* is the kind of senseless harping that
annoys me, Nathan.
> So it's not 100% consistent.
Wrong: It's 100% consistent with the docume
On 9/1/00 8:39 PM, Tom Christiansen wrote:
> What happens on reblessing?
Go back to the old behavior in that case? (Re-blessing has always
smelled like "Perl casting" to me...ick.) Maybe we'd need an "unbless" to
round out the desired (evil ;) functionality.
-John
> >Let me shift gears and instead ask whether anyone thinks this:
>
> >> > $y = ($first, $second) = grep /$pat/, @data;
>
> >Returning "5" has any value? If you're going to do this, it seems like
> >you'd want the number that were really returned (since scalar grep
> >will give you the total n
On 9/1/00 8:32 PM, Damian Conway wrote:
> I'm certainly not averse to a better name -- INIT would be ideal, if it
> weren't already spoken for -- but I think BLESS would be misleading.
Off the top of my head, all I've got are BUILD and MAKE. I don't mind SETUP
though, but BUILD might be a little
What happens on reblessing?
--tom
>>I entreat you to explain to me *anything* that you'd want to tweak
>>with this that you already can't do right now.
>When I need to move Perl files from a default location to a new one. For
>example messing with @INC (and its like). THis could be used for example on
>a machine that has both dev
>Let me shift gears and instead ask whether anyone thinks this:
>> > $y = ($first, $second) = grep /$pat/, @data;
>Returning "5" has any value? If you're going to do this, it seems like
>you'd want the number that were really returned (since scalar grep
>will give you the total number found an
> But I've gotta nitpick the name. I wonder if BLESS wouldn't be better?
> print calls PRINT, printf calls PRINTF, even if the subs don't do any
> printing. Sure makes it easier to see what's going on, to me at least.
But BLESS doesn't do blessing. It does set-up. So it's called SETUP. :
On 9/1/00 8:02 PM, Nathan Wiger wrote:
>> I haven't commented on RFC 171 because I assumed it would be shot down
>> quickly by the Major Contibutors(tm), but let me just say now that I'm
>> firmly in this camp:
>
> Funny, I don't see much difference between RFC 171 and this RFC:
>
> 171: constr
>I entreat you to explain to me *anything* that you'd want to tweak
>with this that you already can't do right now.
When I need to move Perl files from a default location to a new one. For
example messing with @INC (and its like). THis could be used for example on
a machine that has both develop
On Fri, Sep 01, 2000 at 05:50:52PM -0600, Tom Christiansen wrote:
> Why are you using -w instead of use warnings, and can you just imagine the
> howling? This would surely kill your system.
Okay, okay, okay. You're the nth person that brought that up. Yes,
"use warnings" makes more sense than
Damian Conway wrote:
>
> The point of welding SETUP calls to C is that it gives the class
> designer a way of guaranteeing that you can't create an object (i.e. bless
> it) without invoking the initialization.
Actually, this is a good point that I hadn't fully considered. Ok, I've
invoked Larry'
On Fri, Sep 01, 2000 at 05:49:05PM -0600, Tom Christiansen wrote:
> >On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote:
> >Like any other environment variable which the admin wants to be
> >everywhere, put it in /etc/profile. A well configured system will
> >handle it from there.
>
> N
Tom Christiansen wrote:
>
> % man perlfunc
> ...
> When assigning to a list, if LIMIT is omitted, Perl supplies a
> LIMIT one larger than the number of variables in the list, to
> avoid unnecessary work.
As usual I picked a bad example. And I did read the perlfunc manpage,
bu
> What if you want to bless something but not call all its cascading
> SETUPs?
Then don't *define* cascading SETUPS in the first place. :-)
C still would have the existing Perl 5 behaviour. Things
only change if you add these new-mangled SETUP methods.
The point of welding SETUP calls to
On Sat, Sep 02, 2000 at 09:42:09AM +1100, Jeremy Howard wrote:
> I'd like to see negative numbers work. Otherwise the programmer would have
> to explicitly check whether an index into a string was positive or negative,
> take the absolute value, and use pop() or shift() as appropriate.
This has t
> I haven't commented on RFC 171 because I assumed it would be shot down
> quickly by the Major Contibutors(tm), but let me just say now that I'm
> firmly in this camp:
Funny, I don't see much difference between RFC 171 and this RFC:
171: constructor called on object creation
189: construc
> > Furthermore, it proposes that both C and C methods
> > should be invoked hierarchically in all base classes.
>
> This bothers me. It leaves no way to override the behavior of a
> parent's SETUP and DESTROY, you can only overlay. You mentioned that
> this is normal for most
>many systems allow for a global/local startup file for various
>reasons. i see a potential use of this in perl but i don't see the
>specific use yet. build it they will use it.
But Perl is not an interactive shell! Can you imagine if a C
compiler allowed arbitrary amounts of text to be pre-inc
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> How are you going to enable strict in an unrelated lexical scope?
TC> Why are you using -w instead of use warnings, and can you just imagine the
TC> howling? This would surely kill your system.
like i said, i wasn't sure of
>it can be used for system specific @INC paths without
>recompiling perl
That's what PERL5LIB is for.
enforcing strict/-w/-T on all scripts, etc.
How are you going to enable -T from this file you're going to eval?
How are you going to enable strict in an unrelated lexical scope?
Why are you u
>On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote:
>> > "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> >> i think an environment var might be a good way. if it is set, it is the
>> >> file(s) to preload before running your code.
>>
>> TC> You've got PERL5OPT.
>>
>>
> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes:
>> who runs one liners with -T?
MGS> That's the point. .perlrc would effect all perl, including
MGS> one-liners. What's good for big programs is not good for small.
>> what about making the rc files load only if there is cod
On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote:
> > "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
> >> i think an environment var might be a good way. if it is set, it is the
> >> file(s) to preload before running your code.
>
> TC> You've got PERL5OPT.
>
> but that
>but that is the user's to set. PERL_PRELOAD
is there for the user to unset.
>allows the admin to globally
>set (in the system shell rc file) the rc files that perl will load.
And what sorts of things might the admin care to globally set?
--tom
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> i think an environment var might be a good way. if it is set, it is the
>> file(s) to preload before running your code.
TC> You've got PERL5OPT.
but that is the user's to set. PERL_PRELOAD allows the admin to globally
set (in t
On Fri, Sep 01, 2000 at 07:16:13PM -0400, Uri Guttman wrote:
> > "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes:
> MGS> Forcing -T on Will break most existing programs.
> MGS> Makes one-liners annoying.
>
> who runs
On Fri, Sep 01, 2000 at 08:59:10PM -, Perl6 RFC Librarian wrote:
> Furthermore, it proposes that both C and C methods
> should be invoked hierarchically in all base classes.
This bothers me. It leaves no way to override the behavior of a
parent's SETUP and DESTROY, you can only overlay. You
>i think an environment var might be a good way. if it is set, it is the
>file(s) to preload before running your code.
You've got PERL5OPT.
Heck, I bet you could do a cleverness with .perldb, too. :-)
--tom
> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes:
MGS> Here's a little pros/cons list running through my head right now...
MGS> pro con
MGS> Customize @INC We have PERL5LIB
MGS> Forcing -T on
On 9/1/00 5:44 PM, Nathan Wiger wrote:
>> sub SETUP {
>> my ($self, @ctor_data) = @_;
>> # initialization of object referred to by $self occurs here
>> }
>
> Hmmm. I'm not sure if I like this. I like the *idea* a lot, but I must
> say that I think I quite like RFC 171's approach better.
I haven'
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtin: lazy
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Last Modified: 1 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 123
Status: Developing
On Fri, Sep 01, 2000 at 08:59:10PM -, Perl6 RFC Librarian wrote:
> This RFC proposes a new pseudoclass named C.
> This pseudoclass would provide a way of correctly redispatching a method
> or an autoloaded method.
Yay!
I have nothing constructive to say. (Yay!)
--
Michael G Schwern
>Forcing -w on Makes one-liners annoying.
>Makes running existing programs
>annoying.
>We have PERL5OPT
You forgot the con that we've supposed to be "u
On 9/1/00 4:59 PM, Perl6 RFC Librarian wrote:
> Once a hash has been C-ized, the only way to extend its set of
> entries is via another call to C:
>
> sub new {
> my ($class, %self) = @_;
> bless private \%self, $class;
> private $self{seed} = rand; # okay
> $s
On Fri, Sep 01, 2000 at 08:46:50PM -, Perl6 RFC Librarian wrote:
> Many programs have so-called "resource configuration" files (at least
> that's what I call them) that are loaded and executed upon program
> startup. Some example programs that have this ability include bash,
> mutt, and pytho
Let's take an example...
> sub *DESTROY {
> # Perl-special
> }
How would you call this manually, as you sometimes want to do?
*DESTROY $self;
$self->*DESTROY;
So you'd have to redo Perl's parsing of *? Would this override
typeglobs? How would the precedence wo
Michael G Schwern wrote:
> If pop @array, -1 == shift @array, 1 and shift @array, -1 == pop
> @array, 1, and if both Ways To Do It are almost exactly the same, then
> there's no value to allowing negative numbers. In most cases I'd
> expect passing a negative number to be a mistake on the program
Karl Glazebrook wrote:
> I would rather see one largeish RFC integrating all these. More RFCs
> are not necessarily better.
>
The -language WG chair has requested that each RFC contain just one key
proposal, and that multiple related RFCs be drawn together with an overview
RFC.
Karl Glazebrook wrote:
> Can we not keep calling them matrices? They are just a special
> case.
>
Normally I call them tensors, but this is only meaningful to a mathematics
audience.
I was using 'matrix' because both laypersons and mathematicians would know
what the RFCs are referring to. This wo
On Fri, Sep 01, 2000 at 08:38:18PM -, Perl6 RFC Librarian wrote:
> =head1 IMPLEMENTATION
>
> I don't know the gory details other than it should be possible.
Thinking in perl5 terms, its going to require a modification to pp_pop
and pp_shift. The simplest way to do it would be for them to si
>> If you write
>>
>> $burp = LISTIFY( grep {EXPR} @data );
>>
>> What's in the burp?
>By this argument, then why aren't these different?
It depends on whether you think the alpha or beta are
what you want. It's highly unclear why you aren't just
using straight scalar context t
"David L. Nicol" wrote:
>
> No, that would be
>
> dog $spot;
No, it wouldn't:
$r = new CGI;# CGI->new
See?
> You can have your general consensus, I'm not in his army.
Well, unfortunately I think you're doomed to fail then. You're forcing
constraints on yourself that Perl cann
> Email from Nathan Wiger <[EMAIL PROTECTED]> that went to perl6-language
> but I can't find at www.mail-archive.com :-(
Here ya' go:
http://www.mail-archive.com/perl6-language@perl.org/msg02432.html
http://www.mail-archive.com/perl6-language@perl.org/msg02454.html
-Nate
> The typical constructor would then be reduced to:
>
> package MyClass;
>
> sub new { bless {}, @_ }
>
> with initialization handled in a separate C routine:
>
> sub SETUP {
> my ($self, @ctor_data) = @_;
> # initialization of object ref
> From [EMAIL PROTECTED]
Sat Sep 2 08:16:14 2000
> Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1])
>by indy05.csse.monash.edu.au (8.8.8/8.8.8) with ESMTP id IAA21970
>for <[EMAIL PROTECTED]>; Sat, 2 Sep 2000 08:16:14 +1100 (EST)
> Received:
> > 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
At 11:49 AM 9/1/00 -0500, David L. Nicol wrote:
>Dan Sugalski wrote:
>
> > We're shooting for speed here. Any common operation that could be affected
> > by the type of the variable should be represented so a custom function can
> > be called that does exactly what needs to be done.
> >
> >
Tom Christiansen wrote:
>
First off, thanks for taking the time to present such a thorough
document. Well-reasoned arguments is exactly what the Perl 6 project
needs, IMO.
I read this early last night, and have been postulating on it ever
since. In the process of trying what feels like 100's of
> =head1 TITLE
>
> C should simply assert that
> C<(!defined($spot) || $spot-Eisa('Dog'))>
>
> And let them duke it out.
You'd have my support for that...I was intending to release an RFC in the next
day or two that is exactly along those lines.
Damian
At 10:23 AM 9/1/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Type returns a magic cookie value of some sort (Not sure what sort yet),
>: name returns a string with the name of the type of the variable.
>
>Why can't the type object just stringify to the name of the type?
I'd figured that t
At 10:25 AM 9/1/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Anyone got anything to add before I throw together the base vtable RFC?
>
>So how do you call a generic method?
Generic vtable method? You'd have to look up the vtable in the stash that
held it and vector in through there.
If
At 06:07 PM 9/1/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >is_equal (true if this thing is equal to the parameter thing)
> >is_same (True if this thing is the same thing as the parameter thing)
>
>is_equal in what sense? (String, Number, ...)
I was thin
On Fri, Sep 01, 2000 at 03:13:04PM -0600, Tom Christiansen wrote:
> Can't you do this with with an environment setting?
>
> Shell people seem to think this a normal notion, but it's caused
> horrible security flaws in the past. And I couldn't imagine it of
> a C compiler, so I don't know why you
>=head1 REFERENCES
>Christiansen & Torkington, I, pp. 470-472.
>Conway, I, pp. 309-326.
One might add refs to Camel-3's new OO chapter on privacy approaches.
--tom
> Well, Damian is indeed the soul of good taste. Just look at the Latin
> and Klingon modules. Hmm... maybe those weren't such good examples.
I SHOULD KILL YOU FOR THAT!
;-)
I'll release the latest draft of the parameter lists RFC early next week.
I think you'll find the syntax
>=head2 Private methods
>The C keyword could also be applied to subroutines, to restrict
>where they may be called. Access rules similar to those for private hash
>entries would apply:
>package Base;
>
>sub new { ... }
>
>private sub check { ... }
>
Can't you do this with with an environment setting?
Shell people seem to think this a normal notion, but it's caused
horrible security flaws in the past. And I couldn't imagine it of
a C compiler, so I don't know why you would do this one.
--tom
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : NEXT pseudoclass for method redispatch
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 190
Status
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Hierarchical calls to initializers and destructors
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Mandatory and enhanced second argument to C
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 187
S
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Private keys and methods
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 188
Status: Developing
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
smart container slicing
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 191
Status: Developing
=head1 ABSTRA
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Variable-length lookbehind: the regexp engine should also go backward.
=head1 VERSION
Maintainer: Peter Heslin <[EMAIL PROTECTED]>
Date: 9 Aug 2000
Last Modified: 1 Sep 2000
Mailing List: [EMAIL PR
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl resource configuration
=head1 VERSION
Maintainer: Jonathan Scott Duff <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Last-Modified: 1 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 114
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Proposal to rename C and C
=head1 VERSION
Maintainer: Jonathan Scott Duff <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last-Modified: 1 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 3
Number: 74
S
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Proposal to utilize C<*> as the prefix to magic subroutines
=head1 VERSION
Maintainer: Jonathan Scott Duff <[EMAIL PROTECTED]>
Date: 7 Aug 2000
Last-Modified: 1 Sep 2000
Mailing List: [EMAIL PROTECT
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Optional 2nd argument to C and C
=head1 VERSION
Maintainer: Jonathan Scott Duff <[EMAIL PROTECTED]>
Date: 7 Aug 2000
Last-Modified: 1 Sep 2000
Version: 3
Mailing List: [EMAIL PROTECTED]
Number:
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') {
>
> KF> #!/my/path/to/perl
> KF> sub foo_generator { my $a = shift; sub { print $a++ } }
> KF> my $foo = foo_generator(1);
> KF> $foo->();
> Thread-> new($foo);
> KF> Is $a shared between threads or not? If $a is not shared, we've broken
> KF> lexicals.
> Not unless it is so declar
>> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>TC> Well, that depends. Often you must delay till run-time. When Perl
>TC> simply sees something like:
>TC> sub fn { return @blah }
>TC> it can't know whether you'll use that as:
>TC> $x = fn();
>TC> or
>TC> @x = fn();
>T
>I read your message and agree. Not that I liked the idea that much even
>before considering the ramifications. But do you agree that even
>seasoned perlers have trouble anticipating how a list/array is going to
>be converted to a scalar?
A list or array? No, I don't agree. How to predict what
The thing is that so far, Perl has survived on extremely simple
variable types:
SCALAR: singular generic values
ARRAY: ordered lists of SCALARs
HASH: unordered association of SCALARs
Sure, you have special-purpose accessors like the "%" operator or
s/// or pop or exists or even v
Nathan Wiger wrote:
>
> "David L. Nicol" wrote:
> >
> > They gain us compliance with the whims of the people who like barewords
> > for variable names. You may or may not find that to be a good thing.
>
> It's not just that I don't think dropping $'s is a good idea, but that
> is the general co
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;#
> I'm not completely sure what you are trying to do with this RFC.
This RFC describes the programming interface to Perl6 threads.
It documents the function calls, operators, classes, methods, or
whatever else the language provides for programming with threads.
Perl5 has a thread interface, bu
On Fri, Sep 01, 2000 at 10:37:04AM -0800, Michael Fowler wrote:
> I would appreciate you giving me the benefit of the doubt that I'm not
> intentially misunderstanding you.
intentionally
> my $spot isa(Foo);
This should be my $spot : isa(Foo).
Man, these typos are going to be the death o
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
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> Dan Sugalski <[EMAIL PROTECTED]> writes:
>> is_equal (true if this thing is equal to the parameter thing)
>> is_same (True if this thing is the same thing as the parameter thing)
NI> is_equal in what sense? (String, Number, ...)
NI>
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
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> The more interesting case is this:
KF> #!/my/path/to/perl
KF> sub foo_generator { my $a = shift; sub { print $a++ } }
KF> my $foo = foo_generator(1);
KF> $foo->();
Thread-> new($foo);
KF> Is $a shared between threads or not?
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 11:23:16AM -0700, Steve Fink wrote:
> I read your message and agree. Not that I liked the idea that much even
> before considering the ramifications. But do you agree that even
> seasoned perlers have trouble anticipating how a list/array is going to
> be converted to a sca
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
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> Well, that depends. Often you must delay till run-time. When Perl
TC> simply sees something like:
TC> sub fn { return @blah }
TC> it can't know whether you'll use that as:
TC> $x = fn();
TC> or
TC> @x = fn();
TC> or
TC>
1 - 100 of 187 matches
Mail list logo
