On Fri, Jun 29, 2001 at 04:42:57PM -0400, [EMAIL PROTECTED] wrote:
> > It's also not without its faults. Having every instance of a
> > class have different values of ref() could be obnoxious, for
> > example.
>
> Why? You shouldn't be relying on an object's reference. ref $obj eq
> 'Some::Cla
On Sat, Sep 30, 2000 at 01:01:52AM +0100, Nicholas Clark wrote:
> My opinion is that
> The current system is slightly irregular in the way it works.
> A less irregular system would be nicer (hindsight is a wonderful thing)
> It would have been nice to have had a less irregular system to star
On Fri, Sep 29, 2000 at 09:47:00PM -, Perl6 RFC Librarian wrote:
> Classic eval:
>
> eval {}
> eval ""
>
> Unscoped eval
>
> +eval {}
> +eval ""
I like the general idea of this RFC, but the proposed syntax is less than
desirable. What happens with the following?
$result = 20+eval
On Fri, Sep 29, 2000 at 09:20:23PM -, Perl6 RFC Librarian wrote:
> Although consensus so far is against the change, views were from B
> perl users [who do you expect as the majority on perl6 lists? :-)]. The
> change would penalise existing perl users, but benefit new perl users (and
> presuma
On Thu, Sep 28, 2000 at 12:25:32PM +0100, Tom Christiansen wrote:
> You also didn't mention that you would have broken the symmetry between
>
>my Dog $spot;
>our Dog $spot;
No, I didn't mention our Dog $spot should be the same thing, but on an our
variable.
> Or that constructors h
On Thu, Sep 28, 2000 at 10:18:34AM +0100, Tom Christiansen wrote:
> As we sneak under the wire here, I'm hoping someone
> has posted an RFC that alters the meaning of my/local.
> It's very hard to explain as is. my is fine, but local
> should be changed to something like "temporary" (yes, that
>
On Mon, Sep 25, 2000 at 05:49:21PM -0700, Nathan Wiger wrote:
> Michael Fowler wrote:
> > Honestly, if you're using both a stat class and a stat function in your
> > code it's up to you to keep it straight
>
> Exactly my point. So why is this
>
>stat->
On Mon, Sep 25, 2000 at 04:50:32PM -0700, Nathan Wiger wrote:
> Is just as much of a pain because of action-at-a-distance. Solving this
> problem with highly-specific solutions gains us nothing but more
> syntactic inconsistencies and ambiguities, like these:
>
>stat->{'mode'}
>stat->mode
On Mon, Sep 25, 2000 at 03:50:20PM -0700, Nathan Wiger wrote:
> So I assume you're suggesting that this:
>
> stat->{'mode'}
>
> be a call to stat(), which returns a hashref, but this:
>
> stat->mode
>
> would be a call to the method mode() in the class 'stat'
>
> That's not how I read
On Mon, Sep 25, 2000 at 02:17:38PM -0700, Nathan Wiger wrote:
>import Foo;
You're beginning to blur your own fine line here. import is a class method
call using indirect object syntax.
> But notice the disconnect here:
>
>package Foo;
>use base 'Bar';
>
> Seems almost that:
>
>
On Sun, Sep 24, 2000 at 08:52:23PM -, Perl6 RFC Librarian wrote:
> The solution is simple: All barewords must die.
This RFC makes no mention of what happens to the following constructs:
use Foo;
require Foo;
%foo = (bar => "baz");
These are legitimate, non-ambiguous uses of bar
On Thu, Sep 21, 2000 at 10:59:19AM -0700, Steve Fink wrote:
> For lexicals, a use without a declaration makes no sense, because
> variables default to global (non-lexical). A use without an
> initialization is of arguable utility, because your defined() tests may
> already be intended to check fo
Ok, at this point I'm trying to clear up misunderstandings. I believe you
know where I stand with relation to your RFC.
On Wed, Sep 20, 2000 at 06:41:52PM -0700, Steve Fink wrote:
> Michael Fowler wrote:
> > Except for the line number reported, which is the important part.
>
On Wed, Sep 20, 2000 at 05:20:54PM -0700, Steve Fink wrote:
> > $foobal = 3;
> > if (@ARGV) {
> > $foobar = @ARGV;
> > }
> >
> > print $foobar;
> >
> > Only warn me that $foobar is uninitialized? I always prefer it when the
> > actual source of my problem is pointed out,
On Wed, Sep 20, 2000 at 05:10:55PM -0600, Tom Christiansen wrote:
> >Which is silly, because you shouldn't have to say '$x = $x = 3' when you
> >mean '$x = 3'. Just because there's a real reason behind it doesn't make it
> >any less silly.
>
> I'd like to see where this can happen. Sounds like
On Wed, Sep 20, 2000 at 03:25:11PM -0700, Steve Fink wrote:
> > > complains, but
> > >
> > > $x = 3; $x = 3
> >
> > As it shouldn't; you've mentioned $x twice, which means you probably didn't
> > misspell it. That your mentioning twice in this manner is silly is beyond
> > perl's grasp.
>
> Ac
On Wed, Sep 20, 2000 at 07:45:16PM -, Perl6 RFC Librarian wrote:
> "VARIABLE used only once: possible typo" should be replaced with
> warnings on uses of uninitialized variables (including lexicals).
> $x = 3
I don't understand, who's to say you didn't misspell $x? If you're only
using it
On Fri, Sep 15, 2000 at 11:25:31AM -0700, Steve Fink wrote:
> I agree. I'd like q/.../ to stick as close to giving me ... as possible.
> I can live with the current 'foo\\bar' having only one backslash in it,
> but I'd rather not have to worry about anything else. I'd vote for
> Glenn's allowing t
On Tue, Aug 29, 2000 at 07:27:15PM -0700, Peter Scott wrote:
> > $r->{{qw(a b c d e f g h)}}
> > $r->{a}->{b}->{c}->{d}->{e}->{f}->{g}->{h}
>
> $r->{a}{b}{c}{d}{e}{f}{g}{h}
>
> which is only one character longer than the proposal...
Except in the case where you don't have
On Thu, Aug 24, 2000 at 05:24:14PM -0700, Peter Scott wrote:
> At 05:41 PM 8/24/00 -0600, Tom Christiansen wrote:
> >But you don't need that when you can and possibly should just write this:
> >
> > print <<"EOF" =~ /^\s*\| ?(.*\n)/g;
>
> Others may be focussing on th
ceive payment for our legal services.
> |
> | Love and kisses
> |
> EOF
This works for print, but not for other functions where the string is in a
single argument, rather than a list.
printf(
<<<'EOF' =~
On Thu, Aug 24, 2000 at 05:26:36PM -0600, Tom Christiansen wrote:
> >I thought this problem would've been neatly solved by my proposed:
>
> >print <<<"FOO" =~ s/^ {8}//;
> >Attention criminal slacker, we have yet
> >to receive payment for our legal services.
>
> >
On Thu, Aug 24, 2000 at 06:14:10PM -0400, Michael G Schwern wrote:
> Paragraphs.
>
> sub legal {
> print << Attention criminal slacker, we have yet
> to receive payment for our legal services.
>
> Love and kisses
> FOO
> }
>
> Obvi
On Wed, Aug 16, 2000 at 08:22:16PM -0400, Chaim Frenkel wrote:
> >>>>> "MF" == Michael Fowler <[EMAIL PROTECTED]> writes:
>
> MF> So what's insufficient about:
>
> MF> print <<"EOF";
> MF>
On Wed, Aug 16, 2000 at 03:05:23PM -, Perl6 RFC Librarian wrote:
> With a here doc print < the text of the here doc, is processed verbatum. This results in Here Docs
> that either stick out in the code, or result in unwanted leading whitespace.
> There are several FAQs that relate to this pro
On Tue, Aug 15, 2000 at 05:10:34PM -0400, Dan Sugalski wrote:
> The ultimate target of a program's source code is the *programmer*.
> Programmers, being people (well, more or less... :), work best with symbols
> and rich context. Stripping contextual clues out of code does the
> programmer a di
On Tue, Aug 15, 2000 at 04:09:51PM -0400, Ted Ashton wrote:
> Better yet, DWIM. If I write
>
> print "[EMAIL PROTECTED]";
>
> and no array @southern exists, I probably mean I want it to print
>
> [EMAIL PROTECTED]
>
> I'd say, if the variable exists, interpolate it. If not, print it as
On Sat, Aug 12, 2000 at 07:22:01AM +1000, Damian Conway wrote:
> dwim @results, dwim $stuff, @args, %hey;
>
> Can you say 'Lisp'?
Lithp
Michael (who couldn't resist)
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
On Fri, Aug 11, 2000 at 06:36:44PM +0100, Andy Wardley wrote:
> How about any variable created in UPPER case is a constant?
This involves Perl dictating style to the user. Very un-Perllike, IMHO.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator
On Fri, Aug 11, 2000 at 02:52:32AM -0700, Nathan Wiger wrote:
> Jeremy's got a great explanation of this, which I'll paraphrase, but the
> discussion went through lots of iterations. Think of the ^ as a carat or
> thumbtack, holding the place for later variables.
Yea, I ran across the description
I like the idea of currying, it seems powerful and Perlish in many ways.
However, I don't like the currying operator chosen, because of it's ugliness
(IMHO), and its potential for ambiguity (human, not necessarily parser).
So, here is my proposal to change the operator.
from to
---
I couldn't determine if this involves just language, or just internals, so
I'm posting to both. Let me know if this discussion is inappropriate for
one or the other (or both?!).
On Thu, Aug 10, 2000 at 05:08:39AM +, David L. Nicol wrote:
>
> The other advantage of typed languages is that t
On Wed, Aug 09, 2000 at 08:37:35AM -0700, Nathan Wiger wrote:
> > I think a stringified reference is worth seeing, moreso than a simple undef,
> > for debugging purposes if nothing else.
>
> Debugging is great, but I don't think this is the way to do it. The
> reason is some objects might have a
On Tue, Aug 08, 2000 at 07:01:29PM -0700, Nathan Wiger wrote:
> > On Tue, Aug 08, 2000 at 02:18:07PM -, Perl6 RFC Librarian wrote:
> > > Hooks will have to be put in Perl's string context so that if something
> > > is an object, then that object's C method is called
> > > automatically. If no
On Tue, Aug 08, 2000 at 02:18:07PM -, Perl6 RFC Librarian wrote:
> Hooks will have to be put in Perl's string context so that if something
> is an object, then that object's C method is called
> automatically. If no C method is defined, then it should simply
> return undef (instead of printing
On Mon, Aug 07, 2000 at 01:57:14PM +0200, Jean-Louis Leroy wrote:
> package Foo;
>
> sub new
> {
> bless { "${CURRENT_PACKAGE}name" => 'Simpson' ...
> }
>
> ...where $CURRENT_PACKAGE is a special variable automatically set
> to...guess what? ;-)
Is $CURRENT_PACKAGE any different, value-
On Tue, Aug 08, 2000 at 06:22:03AM +1000, Damian Conway wrote:
>> I'm more in favor of a mechanism that makes it easy to build field
>> names from the package name, for those rare cases where you want
>> scoped fields.
[snip]
> See the Tie::Securehash module for a variation on this theme.
> Also
On Mon, Aug 07, 2000 at 02:27:34PM -, Perl6 RFC Librarian wrote:
> This RFC proposes that numeric comparison operators default to stringwise
> comparison when both arguments are non-numeric strings.
>
> =head1 DESCRIPTION
>
> Currently the expression:
>
> "cat" == "dog"
>
> returns t
On Sun, Aug 06, 2000 at 06:29:46PM -0700, Nathan Wiger wrote:
>print $pw;
This resulting in a $pw->SCALAR method call is confusing. $pw is not being
evaluated in scalar context.
>print $pw;
>print scalar $pw;
These resulting in a $pw->STRINGIFY or $pw->TO_STRING call is also
co
On Thu, Aug 03, 2000 at 05:57:45PM +0100, Hildo Biersma wrote:
>'AMQ9506' => [ "Channel '($channel_patt)' has ended because",
> "Channel" ],
>
>'AMQ9508' => [ "The connection attempt to queue manager '(.*?)'
> failed with reason code ($reason_patt)\\.",
>
On Tue, Aug 01, 2000 at 10:27:18PM +0100, Alan Burlison wrote:
> Michael Fowler wrote:
>
> > use typing qw(very-strict);
> >
> > my integer $foo : very-strict = 4;
> >
> > Which would enforce that you can only assign integer constants to $foo
>
On Tue, Aug 01, 2000 at 05:31:56PM -0600, Tom Christiansen wrote:
> >Several people have suggested strong typing as a feature, and have been shot
> >down one by one. However, I think it can be done without forcing it on
> >everyone.
>
> Can it? Are you prepared to make everyone declare the full
On Tue, Aug 01, 2000 at 05:28:08PM -0400, Michael Mathews wrote:
> Unlike many programming languages Perl does not currently implement true
> multiline comments. This can be confusing/tedious to programmers. This could
> be solved by adding a syntax to Perl 6 that would allow for true multiline
>
On Tue, Aug 01, 2000 at 10:09:32AM -0700, Tony Payne wrote:
> The ability to have strong-typing (I don't trust Junior Engineers to get it
> right and I don't have time to check every line of code they write)
Several people have suggested strong typing as a feature, and have been shot
down one by
44 matches
Mail list logo
