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 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 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
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 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 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 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 Fri, Dec 15, 2000 at 11:23:23PM -0800, Ian Hickson wrote:
> So: What I would love to see in Perl 6 is a way of having a single scalar
> that holds a reference to a particular instance's method.
>
> Is there any chance that this would be considered? Or is this already
> possible in Perl 5 but I
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 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 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 23, 2000 at 12:17:18AM +, David L. Nicol wrote:
> Nathan Torkington wrote:
> > The precedent of "if you're doing a hash
> > lookup, use {} around the key" is fairly well-ingrained in Perl.
>
> I don't care how "ingrained" the concept of wrapping the
> field names in curlies is, I
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 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
> mainstream OO languages go). It looks like Do
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 Wed, Aug 30, 2000 at 02:26:08PM +0800, Kenneth Lee wrote:
> dear all,
>
> it seems all the "lvalue sub" RFCs haven't mentioned this.
> currently we can do
>
> $str = "foo bar";
> substr($str, 4, 0) = "baz ";
>
> and $str will become "foo baz bar". should we be able to do
> this with lva
On Wed, Aug 30, 2000 at 08:22:11AM +0100, Hildo Biersma wrote:
> > =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();
On Tue, Aug 29, 2000 at 12:57:07PM -0700, 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
On Tue, Aug 29, 2000 at 10:00:13PM -0700, Nathan Wiger wrote:
> Matt Youell wrote:
> >
> > > mainstream OO languages go). It looks like Dog could be a type of String
> > > subclass.
> >
> > That was my first thought as well. Besides, I'd rather type:
> >
> > my Dog $spot("Spot");
> >
> >
On Fri, Sep 01, 2000 at 11:58:20AM +0200, 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.
And that's what the RFC states. If th
On Fri, Sep 01, 2000 at 12:20:34PM +0100, Hildo Biersma wrote:
> 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
On Fri, Sep 01, 2000 at 05:23:27PM +0200, Slaven Rezic wrote:
> Often, there is the case that "my" is used before actually assigning a
> value to it. For example:
>
> my Foo $foo;
> if ($cond1) {
> $foo = new Foo 1, 2, 3;
> } else {
> $foo = new Foo 2, 4, 6;
> }
>
> I
On Fri, Sep 01, 2000 at 11:41:47AM -0700, David E. Wheeler wrote:
> Michael Fowler wrote:
> >
> > my Dog $spot; # $spot is now a blessed Dog object
> > $spot->name("Fido");# $spot->{'name'} eq "Fido"
> >
> &
On Fri, Sep 01, 2000 at 10:58:36AM -0800, Michael Fowler wrote:
> my $spot isa(Dog);
This should be my $spot : isa(Dog);
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
On Fri, Sep 01, 2000 at 09:09:15AM -0700, Nathan Wiger wrote:
> First off, I think everyone is reading this RFC with the wrong mindset,
>my Dog $spot;
>print ref $spot;# 'Dog'
>$spot = new Dalmation;
>
> No reason this wouldn't still work. The term 'constructor' here is
> misleadi
On Fri, Sep 01, 2000 at 10:37:04AM -0800, Michael Fowler wrote:
> I would appreciate you giving me the benefit of the doubt that I'm not
> intentially misunderstanding you.
intentionally
> my $spot isa(Foo);
This should be my $spot : isa(Foo).
Man, these typos are going t
On Fri, Sep 01, 2000 at 12:35:24PM -0700, David E. Wheeler wrote:
> Well then, that makes this example rather wasteful, doesn't it?
It wasn't an example of how my Dog $spot should be used. I was explaining
to Nate what his code was doing.
> my Dog $spot;
> if ($input eq 'Collie') {
>
On Fri, Sep 01, 2000 at 10:46:50AM +0100, Piers Cawley wrote:
> Are you wilfully misunderstanding me?
I would appreciate you giving me the benefit of the doubt that I'm not
intentially misunderstanding you.
> Let's try another possible example to see if you get the point:
>
> print "What
On Fri, Sep 01, 2000 at 10:22:49AM +0100, Piers Cawley wrote:
> And then there's:
>
> - Makes factory methods impossible.
my Dog $spot;
my $pub = $spot->procreate;
Sure looks like a factory method to me. Just because you don't get to say
my Dog $pup for some optimization doesn't mean
On Thu, Aug 31, 2000 at 09:45:52PM -0600, Tom Christiansen wrote:
> >Well, remember that BEGIN{} blocks are just subs too, with an optional
> >'sub'.
>
> Not exactly. They are not callable, as they disappear immediately.
> More importantly, they have no @_, and things like pop and shift
> act up
On Thu, Aug 31, 2000 at 07:56:24PM -0700, Nathan Wiger wrote:
> > So the object would be left undefined? That means this code:
>
> No, not at all. Remember, everything's going to inherit from CORE, at
> the very least, which would have to provide a CREATE method which just
> instantiates a simp
On Thu, Aug 31, 2000 at 11:48:51PM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> my Dog $spot should call a constructor implicitly
Look at me, replying to my own RFC, how tacky. :)
> If the multi-argument form of the constructor were to be adopted this would
> have to change. Dog->$M
On Thu, Aug 31, 2000 at 05:15:34PM -0700, Nathan Wiger wrote:
> First off, nice additions to the RFC.
Thanks. :)
> > Listed below are constructor alternatives. If a sub is chosen (as in sub
> > PREPARE {}) it will suffer from the disadvantage of potentially causing
> > problems with current
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
Dog $spot syntax is used, a fatal exception is raised. The RFC ment
On Fri, Sep 01, 2000 at 09:34:12AM +0100, Piers Cawley wrote:
> Because, hopefully, there are efficiency gains to be had when perl
> *knows* that $self is a Dog. If it only makes the 'name' method call
> work faster then it's a good result. Admittedly 'bark' is a fairly
> simple function method wi
On Sun, Sep 03, 2000 at 12:42:52PM +0200, Bart Lateur wrote:
> But now you're throwing away the kid with the bathwater.
>
> my Dog $spot;
>
> initially was syntax invented so that $spot was marked as only been ably
> to reference a Dog, with as a result that code internally could be
> opti
On Mon, Sep 04, 2000 at 10:34:37AM +0100, Piers Cawley wrote:
> >> Well then, that's one nay vote. :)
> >
> > Make that two.
>
> Three. But I think Michael already knew about mine and forgot to count
> it.
Heh, I am not counting votes. That was simply me acknowledging his dislike
for the
Well, unless there are any wildly different points someone hasn't mentioned
until now, I'm going to freeze this RFC as it is (with a few minor tweaks).
Various alternate syntaxes have been suggested, but I still rather like
mine. Let Larry do with it what he will. Hopefully he can take somethin
On Mon, Sep 04, 2000 at 10:25:37AM +0100, Piers Cawley wrote:
> Maybe a compromise along the lines of:
>
>my Dog $spot = LIST; # $spot = Dog->new(LIST)
>my Dog $patches; # $patches is undefined but we assert that
> # it'll be a Dog. (Whether you can do
>
[I am not subscribed to the perl6-language-data list, so I would appreciate
it if responses are CC'd to me.]
On Thu, Aug 24, 2000 at 08:45:50AM -0700, Nathan Wiger wrote:
> How is RFC 122 different from RFC 15? Seems like they accomplish a
> similar thing but RFC 15 is a much more Perlish approac
On Fri, Sep 08, 2000 at 04:57:46AM -, Perl6 RFC Librarian wrote:
> =head3 Merge C, C, and C into C
>
> In practice, people rarely make a class that Cs multiple data types
> through the same interface. The reason is that C, C,
> C, and other methods overlap. As such, it is more feasible to
> c
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
---
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
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 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 Wed, Sep 13, 2000 at 11:20:46PM -0700, Nathan Wiger wrote:
[snippity-snip]
> I just think it's a case of "crying wolf", especially when other
> people's CPAN modules start spewing this stuff out from perfectly
> reasonable code, filling up your web error logs with "uninitialized this
> and th
This topic is actually covered, albeit far less in-depth and lumped with an
unrelated change, by Nathan Wiger's RFC 103, just in case you weren't aware.
On Thu, Sep 14, 2000 at 03:57:41AM -0400, Michael G Schwern wrote:
> Methods will be run in scalar context. A method which returns a single sc
On Thu, Sep 14, 2000 at 07:49:32AM -0700, Nathan Wiger wrote:
> > > print 'Today\'s weather will be '.join($", $weather->temp()).
> > > ' degrees and sunny.';
> > >
> > > However if temp() calls wantarray(), the result will be FALSE (scalar).
>
> I think what he's trying to get at i
On Thu, Sep 14, 2000 at 06:37:22PM -0500, David L. Nicol wrote:
> A possibility that does not appear in RFC222.1 is to put tho whole
> accessor expression inside curlies:
>
> print "Today's weather will be ${weather->temp} degrees and sunny.";
>
> which would follow the "You want something
On Fri, Sep 15, 2000 at 10:58:26AM +0200, Bart Lateur wrote:
> MJD has a "silly module" which can tie a hash to a function:
> Interpolation.pm. I think I would like a special case, a specific hash
> that is *always* tied to a function that returns the arguments. Make it,
> for example, %$, %@ or %
On Fri, Sep 15, 2000 at 07:24:39PM -0500, David L. Nicol wrote:
> > The only decision, then, is to decide which context to use; if it
> > deparses to concatenation then it seems logical to use scalar context.
> > This also makes sense in that you can force list context with @{[
> > $weather->temp
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 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 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 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 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,
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 27, 2000 at 09:36:43PM -0400, Bennett Todd wrote:
> > I don't want text to become an object. I don't want numbers to become
> > an object. I don't want to create object regular expressions to call
> > a method on text objects to return back a success object to test with
> > the contr
59 matches
Mail list logo
