[Quoting Nathan Wiger, on August 31 2000, 14:40, in "Re: RFC 132 (v3) Sub"]
sub param {
my ($self, @rest) = @_;
$self-{aval} = @rest if @rest; # See note
lreturn $self-{aval};
}
I've been thinking about this for a couple days. The only problem I see
is that this
Eric Roode wrote:
Adjust your thinking a bit, not the language. Try:
%my_fruit_set = (orange = 1, lemon = 1);
or
@my_fruit_set{qw/orange lemon/} = ();
Yes, probably, this could be easiest... :)
But, maybe because I'm a mulish person, I still thinking that if we
actually use such
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 : 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:
=head1 REFERENCES
Christiansen Torkington, IPerl Cookbook, pp. 470-472.
Conway, IObject Oriented Perl, pp. 309-326.
One might add refs to Camel-3's new OO chapter on privacy approaches.
--tom
On 31 Aug 2000 06:28:10 -, Perl6 RFC Librarian [EMAIL PROTECTED] wrote:
Being one of world's active format users, I have to comment.
Formats out of core / New format syntax
Currently, the general consensus is that formats aren't widely used
enough to justify their living in the core
On Thu, Aug 31, 2000 at 12:34:05PM -0400, Mark-Jason Dominus wrote:
perl6-language-regex
Summary report 2831
RFC 72: The regexp engine should go backward as well as
forward. (Peter Heslin)
This topic did not attract much discussion until the very end of the
week. I sent
Larry Wall wrote:
Karl Glazebrook writes:
: I have a lot of respect for Larry, but as a scientist I distrust all this
: deference to one single authority.
Well, sure, but someone still has to decide who gets the grants. :-)
But it's not always the same person.
: I don't know if Larry
Jeremy Howard wrote:
The RFCs I envisage are:
- Overview of matrix RFCs
- Notation for declaring and creating matrices
- Notation for declaring sparse matrices
- Notation for indexing matrices with a LOL as an index
- ';' for slicing matrices
- @#mat for getting the dimensions of
Buddha Buck wrote:
At 08:10 AM 9/1/00 +1200, Christian Soeller wrote:
No, at least 18. One more piece of semantics that would be appreciated
is optional omission of trailing dimensions in slices, e.g. for a 3-dim
@a:
@a[0:1] == @a[0:1;] == @a[0:1;;]
Would you go for:
I would rather see one largeish RFC integrating all these. More RFCs
are not necessarily better.
"Advanced Perl Multi-dimensional notation".
And n-dim things are not necessarily matrices.
Karl
Buddha Buck wrote:
If I'm stepping on toes here, please tell me...
Here are some suggestions
Ken Fox wrote:
Perl is more like lisp with a good syntax -- in other
words about as far from C as you can get.
I agree 100%.
--
John Porter
Uri Guttman wrote:
the best fit is the TIL (threaded inline code) model we have
discussed.
Yes!
--
John Porter
At 10:46 PM 8/31/00 +, David L. Nicol wrote:
Dan Sugalski wrote:
Okay, here's a list of functions I think should go into variable vtables.
All the math functions are in here. Can the entries that my type does
not use be replaced with other functions that my type does use?
That's what
At 01:44 AM 9/1/00 -0400, Bradley M. Kuhn wrote:
Dan Sugalski wrote:
At 04:59 PM 8/31/00 -0400, Buddha Buck wrote:
At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote:
Okay, here's a list of functions I think should go into variable
vtables.
Functions marked with a * will take an optional
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS Okay, here's a list of functions I think should go into variable vtables.
DS Functions marked with a * will take an optional type offset so we can
DS handle asking for various permutations of the basic type.
DS type
DS name
What are
Tom Christiansen wrote:
Until you start thinking of terms of hashes, you aren't thinking
in Perl. It serves no good to delay this epiphany. Also, remember
that being a "novice" is a temporary and curable condition. Perl
is designed to for long-term ease of use, not short-term learn-free
Buddha Buck wrote:
In a hash implementation, your hash keys -are- your set elements!
my %set;
# add elements to %set
$set{'elem1','elem2'} = 1;
# Compute union
$union{keys %set1, keys %set2} = 1;
Oh, yeah, using native hashes for sets -- what could be simpler?
(Hint:
Bart, until you've read my long message, you're wasting my time.
Please read it.
--tom
Nathan Wiger wrote:
"David L. Nicol" wrote:
my dog $spot;
to
dog spot;
If we only allow this where enough info is available to allocate dog-sized
pieces of memory directly, Perl can blaze through the code that deals with
dogs.
I don't see what barewords gain
If it were possible to assign to the keys of a hash, we'd be
a lot closer to our ideal:
keys(%intersection) = map { exists $set1{$_} ? ( $_ = 1 ) : () } keysSNIP
but this is not currently legal perl.
keys %HASH = LIST;
is really
@HASH{ LIST } = ();
--tom
Tom Christiansen wrote:
If it were possible to assign to the keys of a hash, we'd be
a lot closer to our ideal:
keys(%intersection) = map { exists $set1{$_} ? ( $_ = 1 ) : () } keysSNIP
but this is not currently legal perl.
keys %HASH = LIST;
is really
@HASH{ LIST } =
On Thu, Aug 31, 2000 at 12:34:05PM -0400, Mark-Jason Dominus wrote:
perl6-language-regex
Summary report 2831
RFC 72: The regexp engine should go backward as well as
forward. (Peter Heslin)
This topic did not attract much discussion until the very end of the
Buddha Buck wrote:
Boy, there are a lot of people on that CC: list... Anyone want off
this ride?
How would you recommend the RFC breakdown?
Use ";" for matrix index separator
Use named iterators for matrix indices
anything else?
Everyone else is way past brainstorming but
Nathan Wiger wrote:
Well, this is not bad, only it's not without its problems. Say you
wanted to get your indices implicitly:
@a[getindices()];
@a[$r-get_x, $r-get_y];
@a["@{\(getindices())}"];
@a[join $",$r-get_x, $r-get_y];
Either of these could return an
"David L. Nicol" wrote:
Nathan Wiger wrote:
Well, this is not bad, only it's not without its problems. Say you
wanted to get your indices implicitly:
@a[getindices()];
@a[$r-get_x, $r-get_y];
@a["@{\(getindices())}"];
@a[join $",$r-get_x, $r-get_y];
Bart Lateur wrote:
If you say
keys %hash = 200;
then `%hash' will have at least 200 buckets allocated for
it--256 of them, in fact, since it rounds up to the next power
of two.
This should go away, of course.
--
John Porter
I wonder if it might not be a good idea to implement a function to
compute the intersection of two sets-as-hashes.
Intersection is the only basic set function that's not trivially
implementable with perl hashes. Sure, it's not hard to do, with
a loop and a small bit of programming, but maybe
for reality here. That should be written more like:
1 while FH; $burp = $.;
or even:
for ($burp = 0; my $line = FH; $burp++) {}
I'd go for
my $burp = 0; $burp++ while FH;
This proposal should be dropped.
I read your message and agree. Not that I liked the
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.
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 of
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
"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 fn();
I
"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? If $a is not
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,
"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 fn();
I
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Optional 2nd argument to Cpop() and Cshift()
=head1 VERSION
Maintainer: Jonathan Scott Duff [EMAIL PROTECTED]
Date: 7 Aug 2000
Last-Modified: 1 Sep 2000
Version: 3
Mailing List: [EMAIL PROTECTED]
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 PROTECTED]
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
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
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 consensus as
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 an
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 thinking if
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 the
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
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.
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
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
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
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 to
"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 the system
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.
Not all
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
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
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
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
"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 code not in a
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: constructor
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: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
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
Furthermore, it proposes that both CSETUP and CDESTROY 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
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
=head2 Hierarchical CSETUP calls
It is proposed that when an object is blessed, Iall of the CSETUP methods
in any of its base classes are also called, and passed the argument list
appended to the invocation of Cbless. CSETUP methods would be called
in depth-first, left-most order (i.e.
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:
What if you want to bless something but not call all its cascading
SETUPs?
Then don't *define* cascading SETUPS in the first place. :-)
Cbless still would have the existing Perl 5 behaviour. Things
only change if you add these new-mangled SETUP methods.
The point of welding SETUP
Damian Conway wrote:
The point of welding SETUP calls to Cbless 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
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
Once a hash has been Cprivate-ized, the only way to extend its set of
entries is via another call to Cprivate:
sub new {
my ($class, %self) = @_;
bless private \%self, $class;
private $self{seed} = rand; # okay
On Fri, Sep 01, 2000 at 08:59:10PM -, Perl6 RFC Librarian wrote:
=head1 ABSTRACT
This RFC proposes a new special method called CSETUP that is
invoked automagically whenever an object is created. Furthermore,
it proposes that both CSETUP and CDESTROY methods should
be invoked
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 us
package Derived;
use base 'Base';
sub new {
my ($class, $derdatum, @basedata) = @_;
my $self = $class-SUPER::new(@basedata);
private $self-{data} = $derdata;
"Michael Maraist" [EMAIL PROTECTED] writes:
[...]
First, the current debugger allows multi-lines if you use "\" at the end of
the line ( a la C ).
Thanks. TomC also pointed this out. I still don't like it, though.
(But it will be added to the next revision).
Take a look at what sh will do
Tom Christiansen [EMAIL PROTECTED] writes:
Doesn't that tend to lead us in the direction of pack madness where we
end up with yet another 'sub language' within perl. We've already got
pack specifiers and regexen and the 'old' prototyping stuff. I'm not
arguing *against* these things you
Gael Pegliasco wrote:
First is the choice of arrays verses hashes as the choice for set
storage.
Arrays are obviously easier to construct, but hashes are both faster
implementations, and easier to determine membership.
Well in fact I'm interested by such functions in order to manipulate
$\ = "\n"; print $a = () = qw(a b c);
--
3
All those who expected that the list would be evaluated in array (not
list!) context, raise your hands. Not many, I would think.
What the devil is "array context"? You mean the thing that push expects
for its first argument? Just what
Arrays are ordered.
Hashes are not.
Neither are sets.
Arrays can have repetitions.
Hashes can not.
Neither can sets.
etc.
--tom
Yes, this is true, but the natural syntax, for me, to manipulate sets,
is the one of arrays.
It is not natural to write :
Gael Pegliasco wrote:
Yes, this is true, but the natural syntax, for me, to manipulate sets,
is the one of arrays.
It is not natural to write :
%my_fruit_set = ( 1 = 'orange', 2 = 'lemon' );
but it is natural to write :
@my_fruit_set = ( 'orange', 'lemon' );
I don't want to have to deal
At 03:40 PM 9/1/00 +0200, Gael Pegliasco wrote:
Arrays are ordered.
Hashes are not.
Neither are sets.
Arrays can have repetitions.
Hashes can not.
Neither can sets.
etc.
--tom
Yes, this is true, but the natural syntax, for me, to manipulate sets,
Let's fall back to what we have already:
$\ = "\n"; print $a = () = qw(a b c);
--
3
All those who expected that the list would be evaluated in array (not
list!) context, raise your hands. Not many, I would think.
Read my last letter--the one nobody commented on. What do you
--On 31.08.2000 23:54 Uhr + Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl should support an interactive mode.
Most of what you want is already implemented in the perl shell
available at
Bart Lateur wrote:
On Thu, 31 Aug 2000 13:36:10 -0600, Tom Christiansen wrote:
No. People should learn intrinsic mechanisms with which they can
construct infinitely many beautiful and powerful effects. This empowers
them. Making them learn yet-another-function-call merely hamstrings
them with
The point is that a hash of booleans (not a list of hashes) is a more direct
way to implement a set. A set is unordered, and does not have duplicates.
This is also true of hash keys. Furthermore, the nature of a hash makes it
faster and easier to check for the existance of a key, which is
Bart Lateur wrote:
On Thu, 31 Aug 2000 13:36:10 -0600, Tom Christiansen wrote:
No. People should learn intrinsic mechanisms with which they can
construct infinitely many beautiful and powerful effects. This empowers
them. Making them learn yet-another-function-call merely hamstrings
them with
I don't care about keys when I'm working with sets, and I don't want to
have to deal with them.
Then, if when implementing these new functions in perl6 you choose to
use an invisible hash table, ok, I don't care, but when writing my perl
script I don't want to deal with hash tables for
I already proposed that. Benchmarks show that reading a file with
explicit chomp() is easily 20% slower than reading the same file with
implicit chomp(), through the -l command line switch.
And what, pray tell, do you do about the small matter of wanting
to read some files without implicit
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
For those not on perl6-announce or who thread their mailers...
=head1 VERSION
Date: 31 Aug 2000
Number: 1
Mailing List: [EMAIL PROTECTED]
Chair: Nathan Wiger [EMAIL PROTECTED]
=head1 SUMMARY
The main point which most discussions are currently centering around is
the idea of
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
Nathan Wiger [EMAIL PROTECTED] writes:
=head2 RFC 171 (v1): my Dog $spot should call a constructor implicitly
(Michael Fowler)
This proposed a C++ like constructor mechanism whereby the declaration
of a variable implicitly creates an object. This mechanism would allow
for declarations of
Nathan Wiger [EMAIL PROTECTED] writes:
=head2 RFC 137 (v1): Perl OO should Inot be fundamentally changed
(Damian Conway)
This RFC explored several extensions to current Perl OO in order to make
it more powerful, without sacrificing its current simplicity or
flexibility. Unfortunately, I
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
1 - 100 of 132 matches
Mail list logo
