Re: RFC 270 (v1) Replace XS with the CInline module as the standard way to extend Perl.
On Thu, 21 Sep 2000, you wrote:
This one-liner is a complete perl extension:
perl -e 'print add(2,2);use Inline C="int add(int x,int y){return
x+y;}"'
I haven't written any XS myself, but I was under the impression that one
problem with it is that what you write an extension in (XS) isn't the same as
the language that you're debugging (C). (If this isn't true, then just
ignore this message...) If I were to ever write a Perl extension, I'd like
the code I write to be the same as the code I'm going to debug.
But if Perl6 is changed so that you can write extensions in plain old C
(without using something like Inline), it seems certain that there'd be some
XS compatability tool, so as to not break all the current XS code out there.
So then we could have three ways of writing an extension: straight C, XS, and
Inline. Hmmm There's More Than One Way To Do It? ;-)
--
Matthew Cline| Suppose you were an idiot. And suppose that
[EMAIL PROTECTED] | you were a member of Congress. But I repeat
| myself. -- Mark Twain
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
On Sun, 17 Sep 2000, Perl6 RFC Librarian wrote:
This example shows how much easier it would have been to write the
example on line 170 of perltoot.pod:
package Person;
use strict;
##
## the object constructor (simplistic version) ##
##
sub new {
my $self = {};
$self-{name} :laccess :raccess = undef;
$self-{age} :laccess :raccess = undef;
$self-{peers} :laccess :raccess = [];
return bless $self;
}
Would these attributes carry if you copied the whole array? For that matter,
can you even copy an object an automagically copy the blessing as well?
Urgh. I don't know enough about perl to know if this is doable, or even
desireable. But something like this might be nice:
package Person;
use strict;
# Construct an archtype to make copies of when
# new is invoked
my $archtype = {};
$archtype-{name} :laccess :raccess = undef;
$archtype{age} :laccess :raccess = undef;
$archtype-{peers} :laccess :raccess = [];
bless $archtype;
##
## the object constructor (simplistic version) ##
##
sub new {
return copy_of($archtype);
}
Hmmm. If this is desireable, but not doable, I suppose it would take another
RFC.
Re: RFC: On-the-fly tainting via $^T
On Tue, 01 Aug 2000, Dan Sugalski wrote: At 11:57 PM 7/31/00 -0700, Matthew Cline wrote: Something else which might be useful for tainting would be something like: taint_var($foo); no_taint_var($bar); With this, any value assigned to $foo would become tainted, and any value assigned to $bar would become untainted. While this is certainly doable (heck, you can do it now with tied variables), I'm not at all comfortable with a magic untainting variables. I think it's a rather bad idea. Shrug 'Twas just an off-the-top-of-my head idea; not something I'd really fight for in the inclusion of Perl6. -- Matthew Cline| Suppose you were an idiot. And suppose that [EMAIL PROTECTED] | you were a member of Congress. But I repeat | myself. -- Mark Twain
Re: RFC: On-the-fly tainting via $^T
On Mon, 31 Jul 2000, Nathan Wiger wrote:
Instead, it would be really cool if Perl6 let you do this:
#! perl -T
local($^T) = 0;
$ENV{PATH} = read_config_file();
local($^T) = 1;
I would prefer something like:
#! perl -T
$ENV{PATH} = untaint( read_config_file() );
In other words, either make the 'Taint' and 'Untaint' packages part of the
standard distribution, or put them into the core language.
Something else which might be useful for tainting would be something like:
taint_var($foo);
no_taint_var($bar);
With this, any value assigned to $foo would become tainted, and any value
assigned to $bar would become untainted.
Also:
my $fh = new FileHandle("trusted_config_file");
$fh-setTrusted(1);
Then anything read from $fh wouldn't be tainted, rather than having to
untaint every single thing read from $fh.
--
Matthew Cline| Suppose you were an idiot. And suppose that
[EMAIL PROTECTED] | you were a member of Congress. But I repeat
| myself. -- Mark Twain
