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 it.
TC But Perl
Tom Christiansen wrote:
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.
H. I'm apparently not making myself clear
Kenneth Lee wrote:
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;
Damian Conway wrote:
* invoke some other hierarchy of automagic methods
(REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or
If we do go this way, then we should make sure any names follow suit:
BLESS REBLESS
CREATE RECREATE
INVOKE REINVOKE
SHAPE
On Sat, Sep 02, 2000 at 11:05:23AM +1100, Damian Conway wrote:
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 other OO languages, so I presume there's a way
to deal
Damian Conway wrote:
* invoke some other hierarchy of automagic methods
(REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or
REINCARNATE
In message [EMAIL PROTECTED]
Nathan Wiger [EMAIL PROTECTED] wrote:
For example, in Perl you have for a long time been able to do this:
($one, $two) = grep /$pat/, @data;
However, what currently happens is grep goes to completion, then
discards possibly huge amounts of data
It's called meta shell
ftp://www.guug.de/pub/members/truemper/metash
--
#!/usr/bin/perl -nl
BEGIN{($,,$0)=("\040",21);@F=(sub{tr[a-zA-Z][n-za-mN-ZA-M];print;});
$_="Gnxr 1-3 ng n gvzr, gur ynfg bar vf cbvfba.";{$F[0]};sub t{*t=sub{};
return if rand().5;$_="Vg'f abg lbhe ghea lrg, abj
On Fri, 1 Sep 2000, Tom Christiansen wrote:
it can be used for system specific @INC paths without
recompiling perl
That's what PERL5LIB is for.
PERL5LIB is available for the individual user to use, set, unset, change,
etc., at will. As sysadmin, you can't set it in /etc/profile and be
Michael G Schwern wrote:
Derived classes will never have to override a base's implementation,
and all member variables should be private, and everyone will always
use an accessor, and the UN will bring about world peace, and as long
as I'm wishing for a perfect world, I'd like a pony. ;)
On 9/2/00 11:34 AM, Nathan Wiger wrote:
It doesn't seem that it's that hard to add a single line to your SETUP or
BLESS or whatever method that calls SUPER::SETUP.
I'm pretty sure one of the big points about the system described is that it
ensures both that there's always a predictable and
John Siracusa wrote:
I'm pretty sure one of the big points about the system described is that it
ensures both that there's always a predictable and automatic chain of events
for SETUP/DESTROY (without requiring the programmer to create and document
his own bug-free implementation) and it
The whole notion of blessing is non-obvious enough already.
It's the benedictory (con)not(at)ion of blessing, not the bless()ing
itself that so confuses people, I think.
It bless() were instead named something like
mark
stamp
label
brand
retype
denote
notate
On 9/2/00 12:12 PM, Nathan Wiger wrote:
I think this RFC could work for this, but as I noted in a private email
to Damian I'd rather see a whole new keyword made, maybe "setup"?
sub new { setup {}, @_ }
sub SETUP { ... }
Sure, but does setup() bless? That's the question... :) In other
"Perl6" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
Perl6 This RFC proposes that the second argument to Cbless be made
Perl6 mandatory, and that its semantics be enhanced slightly to cover a
Perl6 common, ugly, and frequently buggy usage.
Yes!
--
Randal L. Schwartz - Stonehenge
On Sat, Sep 02, 2000 at 12:16:48AM -0400, John Tobey wrote:
I agree with Michael that SETUP should be BLESS. You argue that it
Oops, I mean Nate. Sorry, Michael!
-John
So, you don't define a SETUP. BUT, the author of a module you're
inheriting from defined a SETUP, not to your knowledge?
No worse that the current situation in which you have no clue what the
guy you're inheriting from expects. Better to have SETUPs called
below you than to not even
I can most certainly think of cases where a base class's DESTROY does
something a derived class doesn't like. Consider your example,
File::Lock. File::Lock::DESTROY calls flock($fh, LOCK_UN). I derive
File::Lock::Mac from File::Lock. Uh oh, Macs don't implement flock!
Under your
This is from a perl5.7.0 (well the current perforce depot) compiled
with -pg and then run on a smallish example of my heavy OO day job app.
The app reads 7300 lines of "verilog" and parses it with (tweaked) Parse-Yapp
into tree of perl objects, messes with the parse tree and then calls
a method
Perl supplies an operator for line input - angle brackets. This is no
analogous operator for output. I propose "inverse angle brackets":
How about quotes? A quoted lhs expression could mean print. A quoted lhs
expression preceded by a file handle could mean print to filehandle.
Tom
Here is my suggestion: What if other functions were able to backtrace
context and determine how many arguments to return just like split can?
I have an RFC on that:
RFC 21: Replace Cwantarray with a generic Cwant function
Cwant takes a list of strings that describe
Ever consider then having
($a, $b, $c) = FH;
or
@a[4,1,5] = FH;
only read three lines?
I think this is a superb idea, and look forward to someone's RFC'ing it.
Damian
"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];
goes? Your logic suggests that I'd never want to meddle in the base's
implementation.
What happens when the base classes' author finally fixes the problem you
wrote around (and incidentally changes touchy implementation details in the
base)? What happens someday when you can't see the
Also, its not entirely clear why method chaining is desired only for
constructor and destructors. What about every other method?
Constructors and destructors are special. They're not about *doing*
something; they're about *being* (or not being) something.
A "doing" method *may* wish to
The "multiple inheritance paths" one is good. I like that part a lot.
But the rest makes me really nervous if there's no way to override or
change it.
There is. I'll try and get the Cuse delegation RFC out today.
One thing nobody's brought up is this: What if you decide you
On 1 Sep 2000, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Private keys and methods
Here, here amen, Damian! This one gets my instant vote!
David
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 Sat, Sep 02, 2000 at 03:13:17AM -0700, Matt Youell wrote:
What happens when the base classes' author finally fixes the problem
you wrote around (and incidentally changes touchy implementation
details in the base)? What happens someday when you can't see the
implementation of the base
On Sat, Sep 02, 2000 at 03:18:06PM -0400, Mike Lambert wrote:
In certain cases, like the one in which you
proposed, you'd want to explicitly bypass the parent DESTROY.
sub DESTROY {
my $self = shift;
$self-UNIVERSAL::DESTROY(@_);
}
would skip the automatic chaining because the
private $self-{data} = $derdata;
should be $derdatum here?
Yes. Thanks.
Damian
Yes, welcome to the dirty, icky real world. Life sucks, people will
write bad code, you will have to inherit from it. Sometimes you have
to break a little encapsulation to make an omlet. I'd rather it was
not so, but its better to accept it and deal than deny.
Of
"SWM" == Steven W McDougall [EMAIL PROTECTED] writes:
Not unless it is so declared my $a :shared.
SWM Sure it is.
SWM Here are some more examples.
SWM Example 1: Passing a reference to a block-scoped lexical into a thread.
Depends on how locking/threading is designed. There is a fundemental
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
It might be worthwhile enough to kill
sub fn { return (7,8,9,10) }
$x = fn(); # $x == 10
TC But this happens many places. What about @foo[4,1,9,-2]?
TC It's just a listish thing. One should learn.
I don't want that to change. I
Modulo some superpositional silliness,
Hey! I resemble that remark!
Damian
35 matches
Mail list logo
