At 03:30 PM 8/13/00 -0500, David L. Nicol wrote:
>Why not call them throw and catch, like everywhere else,
>and reccomend them over die?
"If everyone else was jumping off a bridge, would you jump too?" (With
apologies to my mom... :)
What everyone else is doing isn't hugely relevant. What we a
At 03:30 PM 8/13/00 -0500, David L. Nicol wrote:
>Whose RFC deals with this?
63, 70, 80, 88 and 96. There would appear to be a groundswell of interest :-)
The mailing list for discussing this is [EMAIL PROTECTED]
>Further discussion in the thread discussed the idea of returning
>to the point
"Randal L. Schwartz" wrote:
>
> Tony Olekshy wrote:
> >
> > Perl should be modified so that if C<$ISA::Search> (or equivalent)
>
> Do you mean "$YOUR_PACKAGE::ISA::Search"
> which is in the package "YOUR_PACKAGE::ISA"?
>
> This would be the first time (to my knowledge) that something would
> be
I'm cc-ing this to p6 because there doesn't seem to be anyone left on p5p.
Let me deal with the easy bit first. I've added a convenience function
called "warnings::warnif" that allows you to write this:
warnings::warnif($category, "message") ;
instead of this:
if (warnings::enabled($ca
On Thu, 10 Aug 2000 18:07:25 +0100, Graham Barr wrote:
>Why not have the return value of AUTOLOAD decide if the search for
>AUTOLOAD should continue ?
AUTOLOAD doesn't explicitely return. It jumps into the loaded routine,
and that one can return whatever it likes. No way to distinguish it from
w
Dave Storrs wrote:
>
> On Fri, 11 Aug 2000, David L. Nicol wrote:
>
> > I've started talking about "containers" instead of arrays and hashes
> > since those both tie directly to implementation details, and containers
> > are abstractions.
> [...]
> >
> > If hashes normally had a sort method of n
> I'm incredibly leery of
> putting two distinct OO mechanisms into Perl. That *won't* satisfy the
> OO purists or those who need guaranteed security.
>
> And I'm *really* against . as an attribute access mechanism :-)
This is my stance as well.
One thing to remember is that we're ripping the
> No, I don't want to tighten up anything about Perl's existing package
> and blessed reference system. It's fine the way it is. I *ALSO*
> want a more formally defined OO system for times when I'm feeling more
> structured, or when the scale or scope of the project I'm working on
Whose RFC deals with this?
Why not call them throw and catch, like everywhere else,
and reccomend them over die? In fact Die could be defined
in terms of throw
sub die(@){ throw(generic_fatal,$!,@_) }
*
Further discussion in the thread discussed the idea of returning
to the point
Just to point out that the standard CS term is "merge".
I guess the opposite would be..."emerge"???
Damian
Peter Scott <[EMAIL PROTECTED]> writes:
>At 07:29 PM 8/10/00 -0700, Glenn Linderman wrote:
>>Thanks for the clarification in your intentions, but isn't _any_ bareword is
>>converted to a string, unless it is in some particular context where a
>>bareword is
>>meaningful (such as filehandle)? So t
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>On Fri, Aug 11, 2000 at 02:09:43AM +0200, Bart Lateur wrote:
>> On Thu, 10 Aug 2000 14:39:39 -0500, Jarkko Hietaniemi wrote:
>
>Did not.
>
>> > people in Newfoundland are going to expect to be
>> >> able to pass in -0230 and have that work, and that's
> I think the idea that => is "just another comma" is pretty widespread
> now.
Just for the record I've always thought this was stupid. That's just my
opinion, true, but there's a fine line between TMTOWTDI and pure
confusion.
IMO, if you're going to have a different operator, make it do somethi
In message <[EMAIL PROTECTED]>
"Ed Mills" <[EMAIL PROTECTED]> wrote:
> Particularly useful for tied hashes using GDBM where the key is actually a
> compound key such as 'Tom Smith+Mycity+NY+13404' we could find all NY-ers
> using
>
> foreach (keys %h) {if (/\+NY\+/) {$h2{$_}=$h{$_}}
>
Bart Lateur <[EMAIL PROTECTED]> writes:
>On Wed, 09 Aug 2000 12:46:32 -0400, Dan Sugalski wrote:
>
>>> > @foo = @bar * @baz;
>
>>Given that the default action of the multiply routine for an array in
>>non-scalar context would be to die, allowing user-overrides of the
>>functions would probably
Piers Cawley wrote:
>$ints_from = ^1 => sub {$ints_from->(^1+1)};
>$ints = $ints_from->(1);
I think pairs should use array range syntax ".." and be folded
into the array generator RFC (or at least referenced in that RFC).
In particular, using a pair in an array context should interpret
t
* Jarkko Hietaniemi ([EMAIL PROTECTED]) [14 Aug 2000 00:15]:
> On Sun, Aug 13, 2000 at 06:54:10PM +1000, iain truskett wrote:
> > * Jeremy Howard ([EMAIL PROTECTED]) [13 Aug 2000 17:28]:
[...]
> > > Personally, I like 'weave' rather than 'zip'. I'm happy with
> > > 'unweave' too--although I'm stil
Bart Lateur wrote:
> On Tue, 08 Aug 2000 23:43:26 -0400, Ken Fox wrote:
> >(assuming min() is polymorphic):
> >
> > min($a, $b) eq $a
> >
> >Ugly, but minimal changes to the language.
>
> We could adopt a syntax similar to sort():
>
> $lowest = min($x, $y, $z); # default: numerical (?)
On Sun, Aug 13, 2000 at 06:54:10PM +1000, iain truskett wrote:
> * Jeremy Howard ([EMAIL PROTECTED]) [13 Aug 2000 17:28]:
> [...]
> > Personally, I like 'weave' rather than 'zip'. I'm happy with 'unweave'
> > too--although I'm still unsure about that one...
>
> Weave is too much like Knuth's tang
* Jeremy Howard ([EMAIL PROTECTED]) [13 Aug 2000 17:28]:
[...]
> Personally, I like 'weave' rather than 'zip'. I'm happy with 'unweave'
> too--although I'm still unsure about that one...
Weave is too much like Knuth's tangle and weave pair of programs for his
WEB idea. *sigh* All the good names a
Nathan Wiger wrote:
> > With zip/unzip/partition
>
> I really gotta say, those functions *need* to be renamed, for a variety
> of reasons. First, they have well-established computer meanings
> (compression, disks). Second, "partition" is too long anyways.
>
> I've seen numerous emails from other p
21 matches
Mail list logo
