Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors
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
Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors
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 hierarchically in all base classes.
I agree with Michael that SETUP should be BLESS. You argue that it
"doesn't do any blessing", ignoring Michael's point about PRINT not
(necessarily) doing any printing.
As you pointed out in the 'MIGRATION' section, such a radical change
to the meaning of DESTROY [w]ould have serious impact. I contend that
a name other than DESTROY should be chosen for recursive-destructor
role. I like CURSE, though maybe ABSOLVE will better please the
unperverted among us. Then object reblessing would naturally call
CURSE via the old package and BLESS with the new. If reblessing is
not itself condemned, that is.
use base map { "Base$_" } 1 .. 999;
{
my $x = bless {}; # a thousand blessings
}# a thousand curses (m+s vs refcounting aside)
=head2 The CSETUP method
It is proposed that, if a class has a method named CSETUP, that method
will be invoked automatically during any call to Cbless. It
is further proposed that Cbless be extended to take an optional argument
list after its second argument, and that this list would be passed to
any CSETUP method invoked by the Cbless.
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?
Better, have UNIVERSAL::new load the args into a hash and pass it to
SETUPs by reference, avoiding positional-parameter hell. SETUP can
delete what it processes and insert what its bases need.
UNIVERSAL::new can even warn about "unrecognized initializer arg" if
there's anything left in the hash when SETUPs have finished. See my
experimental UNIVERSALs below.
Note that CBase2::DESTROY is only called once (as late as possible),
even though class Rederived inherits it through two distinct paths.
Let's get the single-inheritance case nailed down before we think
about how it should work in MI. With Perl's interface inheritance (a
term for which I thank you, Damian), who knows? Maybe some base
classes don't want to be virtual.
=head2 Proposed standard CUNIVERSAL::new
Given that most Perl classes are hash-based and that the CSETUP method
cleanly separate construction and initialization, it might be desirable to
have the UNIVERSAL class always supply a default constructor:
package UNIVERSAL;
sub new { bless {}, @_ }
Yes, and it could call SETUP the way you want, eliminating the need to
change the 'bless' builtin. There could even be a UNIVERSAL::SETUP
that looks for args from %FIELDS (or its successor) in its initalizer
hash. Below is something along these lines that I put together last
year. It relies on pseudohash semantics, but the principles are
what's of interest.
package JTobey::UNIVERSAL;
sub new {
if (scalar(@_) =~ /[02468]$/) {
require Carp;
Carp::confess ("Missing value for last initializer");
}
my ($pkg, %args) = @_;
my ($obj, $fields);
{ no strict 'refs'; $fields = \%{"$pkg\::FIELDS"}; }
$obj = bless [$fields], $pkg;
$obj-init (\%args);
if (%args) {
require Carp;
Carp::croak ("Initializer list contains unrecognized fields: "
.join(", ", keys %args));
}
return $obj;
}
sub init {
my ($obj, $argsref) = @_;
my ($fields, $pos);
$fields = $$obj[0];
foreach my $name (keys %$argsref) {
next if not $pos = $$fields{$name};
$$obj[$pos] = delete $$argsref{$name};
}
}
# Break circular references.
sub free {
@ { $_[0] } = ();
}
-John
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
On Tue, Aug 08, 2000 at 10:47:10PM -0700, Russ Allbery wrote:
John Tobey [EMAIL PROTECTED] writes:
On Wed, Aug 09, 2000 at 02:22:22AM +0200, Bart Lateur wrote:
date() would be more general, and replace both. You can pass it a time
zone, ANY time zone, and it will tell you what time it is in that time
zone.
You're proposing embedding the full power of the Olson TZ library into
Perl core. This is a nontrivial amount of data that changes four or five
times a year. I really don't think this is a good idea. Furthermore, the
only time zone database that can actually do this doesn't use the naming
scheme that you're probably used to.
The JTobey::Date module uses the TZ environment variable (which, I'm
told, is non-portable), the esoteric POSIX routines tzset and tzname,
and some functions from the CPAN modules Date::Parse and Date::Format.
It's far worse than non-portable; it's completely insufficient. The POSIX
TZ syntax cannot represent many real time zones. You need the Olson-style
naming scheme which refers to entries in a fairly large external database
You mean the "EST5EDT", "US/Pacific", "America/New_York", and suchlike
files in /usr/share/zoneinfo. Actually, I do use those indirectly,
though probably non-portably, by localizing C$ENV{TZ}. GNU Libc
takes care of finding the zoneinfo file, but lamentably reparses it
every time TZ changes and CPOSIX::tzset is called.
My module does not parse old-style TZ formats, though some other
module (Date::Format or Time::Zone?) does.
-John
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
On Wed, Aug 09, 2000 at 02:22:22AM +0200, Bart Lateur wrote: I have a server in the UK, while I'm in Belgium. Different time zones. So localtime() won't return the time in *my* localtime. So we have two almost identical functions in the core, gmtime and localtime, where one gives an offset of zero, and the other an offset based upon the time zone settings of your system. It's a very small difference. Those are the most commonly requested time representations, but as in my example, it's not enough. date() would be more general, and replace both. You can pass it a time zone, ANY time zone, and it will tell you what time it is in that time zone. Multiple timezone support in a single process should definitely be supported, *ideally*. I don't think this RFC is even proposing that. It is very difficult to do right. I spent several months trying; you can see my work using these CVS commands: echo :pserver:[EMAIL PROTECTED]:/home/cvs A ~/.cvspass cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs co Date The JTobey::Date module uses the TZ environment variable (which, I'm told, is non-portable), the esoteric POSIX routines tzset and tzname, and some functions from the CPAN modules Date::Parse and Date::Format. It is designed to give it all an easy OO interface, and to be as correct as possible on systems like mine. It is not expected to be very fast, portable, or locale-friendly. To overcome these problems would be a Herculean task which I simply doubt that anyone here is willing to do. Therefore, I oppose the notion that Perl 6 will magically handle all this. -John
AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
On Mon, Aug 07, 2000 at 01:44:28AM -0500, Jonathan Scott Duff wrote: On Sun, Aug 06, 2000 at 11:07:02AM -0700, Russ Allbery wrote: Basically, you don't want to go anywhere near this mess; it eats people. I agree. I see two reasonable options to go with instead. One is to just use a binary flag that says use UTC or not; this is the simplest and most reliable to explain. The other is to allow a timezone offset; this doesn't deal with daylight savings time and historic time zone changes, but it provides enough power for most of what people want to do and if you want to deal with the rest you have to deal with time zone naming. I agree completely with Russ, and I would further state that I don't want this Cdate feature in the core. Dates, times, timezones, leap seconds, month and day names, localized formats, etc., are too complex. No one here has thought out the complexity enough to say "this is what Perl will support from now on". Currently, there isn't even an adequate (in my opinion) module on CPAN that gives dates a proper abstract interface. Time::Object may be okay as a lightweight localtime/strftime interface, but it does not support date, as opposed to time/date, arithmetic, or rather, it mis-supports it. Since we really don't understand dates here, I don't want us commiting to a certain interface without a `use' directive in the program. Distribute Time::Object as a standard module, but keep it a module, and don't force its quirks on people. Certainly, don't force the complex, quirky, and untested interface being developed here now on anyone without a long, patient discussion period. This makes an incredible amount of sense. We could even let the user specify a coderef to a sub that implements their own particular timezone oddities. (i.e. a sub to tell date() what the TZ offset is) Gross. Put it in a module. -John
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
On Sun, Aug 06, 2000 at 01:41:06PM -, Perl6 RFC Librarian wrote:
$scalar = date; # scalar ctime date, same as current
@array = date; # array of date/time values (new order)
%hash= date; # hash of date/time values (new)
$object = date; # object with accessor functions (new)
The new Cdate() function will return time adjusted for the local
timezone. To get UTC (or GMT, for nostalgic types) time, you simply pass
an argument to Cdate().
Please don't gloss over the timezone issue so easily. There is
nothing simple about timezones (except for GMT, of course). The
reason there are *NO* good OO date modules on CPAN is that people fail
to realize what nastiness comes from sticking in timezone support as
an afterthought.
For example, Time::Object's interface practically precludes adjusting
for daylight savings when doing date (as opposed to date/time)
arithmetic:
#!/usr/local/bin/perl -w
$ENV{'TZ'} = 'US/Pacific';
use Time::Object;
use Time::Seconds;
print "$Time::Object::VERSION\n";
$t = localtime 954547200;
print $t, "\n";
print $t - 30 * ONE_DAY, "\n";
print $t + 30 * ONE_DAY, "\n";
=
add
0.11
Fri Mar 31 16:00:00 2000
Wed Mar 1 16:00:00 2000
Sun Apr 30 17:00:00 2000
Notice that adding 30 days to March 31 has the (probably unwanted)
effect of changing the time from 16:00 to 17:00. Dates and date/times
are just entirely different beasties due to the horrible (and
senseless, btw) complexity of daylight savings time rules.
-John
proto-rfc. Elements of @_ should be read-only.
This is not quite finished yet, as I read the rest of the C-- garbage collection paper. -John =head1 TITLE Elements of @_ should be read-only =head1 VERSION Maintainer: John Tobey [EMAIL PROTECTED] Date: 3 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: =head1 ABSTRACT Unprototyped subs should not be allowed to modify their callers' data simply by assigning to elements of the arg array. This form of passing by reference is obsolete now that Perl has hard references and C\$ in prototypes. The feature is confusing, since it means that the recommended convention for naming parameters (by assigning C@_ to a Cmy list) alters semantics. The Perl 5 (and older) behavior may preclude some optimizations. =head1 DESCRIPTION Bla bla bla, optimization. Bla, bla, native code, pass by value. C-- is cool. =head1 IMPLEMENTATION A fascist implementation would emit a compile-time error any time C@_ or one of its elements were assigned to, taken a refernce to, etc. A friendlier version would automatically copy the arg value to a new temporary. This change would mean a moderate Perl 5 compatibility breakage. The Perl-5-to-Perl-6 converter could insert whatever trick is used to obtain the Perl 5 behavior (perhaps a C(@) prototype) when it detects argument modification. If the optimization suggested above is implemented, it would cause another wave of breakage, as arg-modifying subs would have to be defined or prototyped above the places where they are called. A pragma to restore the old behavior would be the safest guarantor of compatibility. =head1 REFERENCES Lperlsub, The C-- homepage - http://www.cminusminus.org/
Re: RFC: On-the-fly tainting via $^T
Simon Cozens [EMAIL PROTECTED] wrote: On Tue, Aug 01, 2000 at 01:43:05PM +0100, Graham Barr wrote: Let me just say that Larry has said in the past that untainting was deliberatly left difficult to do, on the basis that something which can have serious effect (ie security) should not be easy to do. But then I suppose all previous decisions are up for re-deciding Yes, they are. If we're going to make it trivially easy to untaint, should we bother having tainting at all? :( Tainting has potential uses as data-tracking mechanism aside from security. If the keyword 'untaint' had to appear, it would be easier to find security issues than when m/(.*)/ is used. Uh-oh, now we're getting back into perl6-language territory... attempting to CC. -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
