Leopold Toetsch wrote:
Given is a Perl snippet like:
{
my $fh = IO::File->new;
$fh->open(">test.tmp");
print $fh "a";
}
The filehandle is closed automatically at scope exit and the file
contains the expected contents.
That's quite easy in the current Perl implementation as it d
>>>>> "Hildo" == Hildo Biersma <[EMAIL PROTECTED]> writes:
Hildo> I'm looking at writing Parrot support for a vendor library: IBM MQ
Hildo> (Message Queueing, aka "MQSeries", aka "WebSphere MQ"). The current
Hildo> perl mod
> "Nick" == Nicholas Clark <[EMAIL PROTECTED]> writes:
Nick> On Mon, Aug 09, 2004 at 08:53:27AM -0400, [EMAIL PROTECTED] wrote:
>> - MQ has constants. Thousands of them. In the perl module, these get
>> mapped to perl XS subroutines (which bloats the symbol table no
>> end). For parrot, I'd
I'm looking at writing Parrot support for a vendor library: IBM MQ
(Message Queueing, aka "MQSeries", aka "WebSphere MQ"). The current
perl module (which I maintain) uses XS code and Parrot's NCI should
simplify this a lot.
I have two questions though:
- MQ has some data structures that are a ta
> "Bryan" == Bryan C Warnock <[EMAIL PROTECTED]> writes:
Bryan> Using Multiple Versions Of The Same Module In One Program
Bryan> There are a lot of reasons why this isn't a good idea, or even
Bryan> possible in places. Non-Perl code on the backend, for
Bryan> instance, will probably prevent
> "Dave" == Dave Storrs <[EMAIL PROTECTED]> writes:
Dave> When you want to install a new version, you simply prepend it
Dave> with its version number (or insert it at appropriate place).
Dave> The order is, of course, irrelevant...you can order it as 1.3,
Dave> 2.0, 1.0 if you want, but the
Damien Neil wrote:
>
> On Wed, Dec 27, 2000 at 02:06:45PM -0500, Hildo Biersma wrote:
> > I don't recall the bit sizes to be in ANSI C. Which paragraph is that
> > in?
>
> You need to deduce the bit sizes, as the standard doesn't speak in
> terms of bits.
Damien Neil wrote:
>
> On Wed, Dec 27, 2000 at 10:46:03AM -0500, Philip Newton wrote:
> > So a native int could be 8 bits big? I think that's allowed according to
> > ANSI.
>
> ANSI/ISO C states:
> char <= short <= int <= long
>
> char >= 8 bits
> short >= 16 bits
> int >= 16 bits
>
"Bradley M. Kuhn" wrote:
>
> > On Wed, 6 Dec 2000, Bradley M. Kuhn wrote:
> >
> > > And, it will make the barrier for entry for new internals hacker lower.
>
> Sam Tregar <[EMAIL PROTECTED]> wrote:
>
> > Really? Do you honestly believe there are more Java programmers than C
> > programmers? P
Nicholas Clark wrote:
>
> On Mon, Oct 23, 2000 at 06:25:44PM -0700, Ask Bjoern Hansen wrote:
> > :-) For those who haven't read them the Steve Maguire books are
> > really really good. Hallo, no matter what you think of the software
> > they shrinkwrap and sell they must (as a huge software comp
Nicholas Clark wrote:
>
> What do you mean by "need"? Strings need to be able to contain single
> quotes, but single quotes are not the only way to build a string. Single
> and double quotes don't generate a different fundamental type; a double
> quoted string with no variable interpolation also
> =head1 ABSTRACT
>
> Currently, C<\1> and $1 have only slightly different meanings within a
> regex. Let's consolidate them together, eliminate the differences, and
> settle on $1 as the standard.
Sigh. That would remove functionality from the language.
The reason why you need \1 in a regu
> =head1 ABSTRACT
>
> Remove all interpolation within single quotes and the C operator, to
> make single quotes 100% shell-like. C<\> rather than C<\\> gives a single
> backslash; use double quotes or C if you need a single quote in your
> string.
Single-quoted strings need to be able to conta
Perl6 RFC Librarian wrote:
>
> =head1 ABSTRACT
>
> Perl is frequently used in CGI environments. It should be as easy to write
> CGI programs with perl as it is to write commandline text filters.
>
> =head1 DESCRIPTION
>
> Tom Christiansen proposed this in his perl6storm message:
>
>
> > =head1 NOTES ON FREEZE
> >
> > The only comments received were on my crappy examples, which have been
> > clarified. Everyone seemed to like the idea.
>
> Personally I hated it. And I distinctly remember saying so. And I
> still hate it.
I dislike it too. URIs are a user-space matter and sh
Bart Lateur wrote:
>
> On Sat, 16 Sep 2000 10:26:48 +0100, Hildo Biersma wrote:
>
> >> length(@ary) deserves a warning
> >
> >Right now, the Lint back-end gives a warning in these cases (use of
> >array in scalar context).
> >
> >Can we make th
> =head1 ABSTRACT
>
> Pseudo-hashes and the associated fields pragma shoule be removed from
> Perl 6.
A few counter points:
Removal of pseudo-hashes should not stop us from using this (or a
similar mechanism) under the covers in perl6 to implement strongly typed
objects.
AFAIK, most of the pai
> =head1 TITLE
>
> length(@ary) deserves a warning
Right now, the Lint back-end gives a warning in these cases (use of
array in scalar context).
Can we make the RFC more generic, and propose to move the Lint warnings
into the core?
Hildo
Nathan Wiger wrote:
>
> > I think such modules are a bad idea, because their functionality is
> > typically restricted.
>
> What, you mean like CGI.pm ?! :-)
Yes, restricted. If you use the procedural interface to a module that
supports both OO and procedural interfaces, you're basically at th
John Porter wrote:
>
> Hildo Biersma wrote:
> >
> > I think such modules are a bad idea, because their functionality is
> > typically restricted.
>
> Oh? Where do you get that idea?
Think about it. If a module supports both an OO and a procedural
interface, t
Nathan Wiger wrote:
> >
> > and this may, indeed, be sufficient.
>
> Remember, this still won't solve the problem of a module whose functions
> can handle both OO and function-oriented calls - and yes, I have many
> that do this. :-)
I think such modules are a bad idea, because their functional
Piers Cawley wrote:
>
> > This is a bit dangerous, since we can get into ambiguities again.
> > If I have A::B::C::Foo, A::B::C::Bar, X::Y::Z::Foo and X::Y::Z::Bar,
> > I'd like to use shorthands for A::B::C's Foo and X::Y::Z's Bar at the
> > same time.
>
> Well you can't. The patch that I pinc
Piers Cawley wrote:
> =head1 ABSTRACT
>
> Cnew>
> is a pain in the bum to type. We should replace this with
>
> use namespace 'Big::Long::Prefix';
> my ::Class $object = ::Class->new;
This is a bit dangerous, since we can get into ambiguities again.
If I have A::B::C::Foo, A::B::C::Bar
> =head1 TITLE
>
> Make length(@array) work
Counter-proposal: make length(@array) a syntax error. I don't feel like
rewarding stupidity, I'd rather teach people how to do things properly.
Hildo
Piers Cawley wrote:
> =head1 ABSTRACT
>
> The behaviour of the syntax should simply be an
> assertion of the invariant:
>
>(!defined($spot) || (ref($spot) $spot->isa('Dog)))
Apart from the buglet that Damian pointed out, agree.
Instead of an implementation based on tie, I'd rather define
Bennett Todd wrote:
>
> I think the complaint about mod_perl's weight bears looking at,
> despite the success of the INN embedding. One invocation of INN is
> likely to do a sufficiently heroic amount of work that the weight
> and bulk of a perl in there may well not hurt a bit.
>
> A single htt
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
>
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 a
Perl6 RFC Librarian wrote:
>> =head1 DESCRIPTION
>
> What is currently an optimization for pseudo-hashes:
>
> my Dog $spot = Dog->new();
>
> should be replaced with:
>
> my Dog $spot;
>
> which calls an implicit constructor (discussed further in the IMPLEMENTATION
> section). The opt
> =head1 ABSTRACT
>
> There needs to be a way for an object class to define C format
> specifiers for use in formatting objects into strings with C and
> C.
I find myself agreeing with your sentiment, but the approach in this RFC
is not sufficiently general. Why only provide hooks for printf, n
Jonathan Scott Duff wrote:
>
> On Tue, Aug 29, 2000 at 11:04:26PM -0400, Michael Maraist wrote:
> > First greatly stylistic compatibilty. An inexperienced programmer would
> > see:
> > my Dog $spot = "Spot";
> >
> > And become confused. It's totally unintuitive (at least so far as other
> > mai
Matt Youell wrote:
>
> So perhaps sometimes in Perl we could say:
>
> my Dog $spot = undef;# Automagically knows to be a Dog ref instead
> of a Dog object because of the undef.
> if ($age > 12) {
> $spot = new Doberman();
> } else {
> $spot = new Corgi();
>
> =head1 TITLE
>
> my Dog $spot should call a constructor implicitly
>
What, then, happens to the following code:
my Dog $spot;
if ($age > 12) {
$spot = new Doberman();
} else {
$spot = new Corgi();
}
Would you seriously propose to create a Dog object, then wipe it in
either branch if
Nathan Torkington wrote:
>
> Damian Conway writes:
> >> sub foo :lvalue { $foo }
> >> post foo { die if $foo == 5 }
> >>
> >> eval {
> >> foo() = 5;
> >> };
> >
> > Postconditions on lvalue subs are not tested until the end of the complete
> > expression in whi
Tom Christiansen wrote:
>
> >If the behind-the-scenes shenanigans are invisible and performance is at
> >worst acceptable, does it really matter how things are implemented?
>
> So long as you can still say things like
>
> perl -le 'print scalar getpwuid(1)'
>
> and that script still contin
> =head1 TITLE
>
> Replace $self in @_ with self() builtin (not $ME)
>
Don't impose your religion on others. If people want 'this' instead of
'self', that should be just fine.
It should be pretty easy to define the appropriate $ME-reader like this:
use ObjectStyle 'self';
or
use Object
Larry Wall wrote:
>
> I expect that we'll get more compile-time benefit from
>
> my HASH sub foo {
> ...
> }
>
> %bar = foo();
Ah, the Return Value Optimization so loved in C++...
For those who haven't seen it before, you can optimize this by passing
in a reference to %bar
I disagree with this in so many places that I don't really know where to
start...
First, I do agree with the view perl should have better support for
classes. Also, should the author want to, protection features from C++
(or other B&D languages) should be supported optionally.
> NOTE: these and
"David L. Nicol" wrote:
>
> Hildo Biersma wrote:
> >
> > > =head1 ABSTRACT
> > >
> > > Herein a new syntax is introduced to specify a sort function
> > > for the keys of any hash.
> > >
> > > =head1 DESCRIPTION
>
Simon Cozens wrote:
>
> I'm obviously missing something about vtables. It'll be obvious when someone
> corrects me, but...
>
> Currently, SvPVX(foo) requires one lookup; with a vtable, it would necessitate
> two, (One to find the functino in "foo", and then the functino must find the
> data in "
> =head1 ABSTRACT
>
> Herein a new syntax is introduced to specify a sort function
> for the keys of any hash.
>
> =head1 DESCRIPTION
>
> %professors{ $a->name cmp $b->name };
I feel the sort order should be specified on the iterator, not on the
hash variable. It should be possible to
"David L. Nicol" wrote:
>
> What if its a method of anything in an array? $_ is already
> a reference to the object on the array in for loops rather
> than a copy of it. What if we make change be not something about
> for loops, but about anything in an array?
>
> print "The index, in
> =head1 ABSTRACT
>
> This RFC proposes that subroutine argument context specifiers be
> extended in several ways, including allowing parameters to be typed and
> named, and that a syntax be provided for binding arguments to named
> parameters.
I agree with most, if not all, of this RFC.
> =h
Chaim Frenkel wrote:
>
> DC> =head1 IMPLEMENTATION
>
> DC> Definitely S.E.P.
>
> What does that mean?
Somebody Else's Problem. From one of the Douglas Adams novels.
> =head1 DESCRIPTION
>
> Many other programs have so called "resource configuration" files (at
> least that's what I call them) that are loaded and interpretted upon
> program startup. Some example programs that have this ability include
> bash, mutt, and python. Perl should do the same.
>
> A
Steve Simmons wrote:
>
> On Wed, Aug 16, 2000 at 08:03:31PM -, Perl6 RFC Librarian wrote:
>
> > Perl should provide a mechanism to have common code autoloaded from a
> > file. . . .
>
> > A C file could be used to set system-wide defaults that
> > the system administrator would like to prom
Matt Sergeant wrote:
>
> [I might join perl6-language some day, but until then, please CC me on all
> Time::Object related messages]
>
>
> On Wed, 2 Aug 2000 08:14:22 +0100 (BST), Matt Sergeant wrote:
>
> >I used to be a C programmer myself (well OK, I was a C++ programmer...),
> >but I'd rat
47 matches
Mail list logo
