On 8/16/00 12:37 PM, Perl6 RFC Librarian wrote:
> This RFC proposes that the current constant.pm module removed, and
> replaced with a syntax allowing any variable to be marked as constant.
Unfortunately, I submitted an nearly identical RFC yesterday because I
didn't see the existing one (I searc
On 8/16/00 3:55 PM, John Siracusa wrote:
> On 8/16/00 12:37 PM, Perl6 RFC Librarian wrote:
>> This RFC proposes that the current constant.pm module removed, and
>> replaced with a syntax allowing any variable to be marked as constant.
>
> Unfortunately, I submitted an
On 8/16/00 4:00 PM, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Better constants and constant folding
>
> =head1 VERSION
>
> Maintainer: John Siracusa <[EMAIL PROTECTED]>
> Date: Aug 15 2000
> Version: 1
> Mailing List: [EMAIL PROTECTED]
> Number:
On 8/18/00 11:56 AM, Larry Wall wrote:
> I'm not sure we have to throw out the orthogonality of OO to data
> structure to get what you want.
Do you mean orthogonality of syntax or implementation? Or both?
It seems like it might be both cleaner and easier to allow "Perl 5 o-o" to
live on largely
On 8/28/00 2:35 PM, Tom Christiansen wrote:
>> Object-oriented features were added to Perl with version 5, and in many
>> ways still appear somewhat "tacked on", with perhaps undue respect
>> for the Old Ways of Perl 4.
>
> [NB: This is not a serious missive.]
>
> Hey, that Perl uses packages fo
On 10/2/00 1:56 PM, Bart Lateur wrote:
> The problem with XML is that it is so unforgiving; I think somebody
> already mentioned that. Improperly nested tags, or one character it
> doesn't recognize... and the parser says "nyet".
Kind of like Perl, huh... ;)
(this is a feature, not a bug! :)
-Jo
On 10/2/00 4:44 PM, John Barnette wrote:
> * Advanced concepts that POD cannot contain that the XML junkies
> might want to be used can be embedded. (=for XML)
Yeah, but then you get =for HTML, =for XML, =for 3DHOLOGRAM, whatever. No
one does that because no one wants to make 50 versions of the
On 10/3/00 10:59 AM, John Porter wrote:
> John Siracusa wrote:
>> POD is supposed to be the common format that can be transformed into other
>> representations. Instead, you have to add the different representations
>> yourself if you do anything remotely complex.
>
>
On 10/3/00 12:01 PM, John Porter wrote:
> John Siracusa wrote:
>>> If you add (e.g.) support for tables, then pod is only translatable
>>> into languages which also support tables.
>>
>> What languages *don't* support tables?
>
> I knew that was a
Not to seem ungrateful, but is there any hope of getting the slides up as
well? You'd think it'd be a no-brainer, but there have been many Wall
speeches that have gone by with no slides on the web (well, none that I
could find, anyway.) I want to know what the audience is laughing at... :)
-Joh
On 4/6/01 2:17 PM, Larry Wall wrote:
> P.S. Larry's Second Law of Language Redesign: Larry gets the colon.
My initial reaction: Larry can keep it! ;)
(go ahead, make me a believer... :)
-John
On 4/23/01 3:25 PM, Larry Wall wrote:
> : >From a trainer's point of view, having two operators which look very
> similar, : are used for the same thing in various different languages, and do
> *almost* : the same thing but not quite, is completely *asking* for confusion.
>
> So teach 'em :=, and
On 4/23/01 3:59 PM, Nathan Wiger wrote:
>> Then how do you concatenate a number?
>
> Here's something I was thinking about at lunch:
>
> $concated_number = "$number" + "$other_number";
> $numerical_add = $number + $other_number;
>
> Why not require "" in the case when you want to forcible c
On 4/23/01 4:16 PM, Larry Wall wrote:
> What is it about . that seems to inspire allergic reactions in people?
> Surely it's not the . itself, but the requirement that you fit everything
> into that one syntactic mold. Perl's not going to do that.
I don't mind it, but I always imagined:
$ob
On 4/25/01 5:52 PM, Dan Brian wrote:
> the idea of a "dereference operator" dumbfounds lots of folks. "What's an
> object got to do with a reference, much less a pointer?" A p5 object is very
> confusing to others for this reason, and so is the syntax.
Then remove it from the reference syntax! :)
On 5/4/01 11:09 PM, Nathan Wiger wrote:
> The real trick is what to do with these:
Note: stabbing wildly here... :)
> %a = (%b, %c);
%a = (stringify(\%b) => \%c); # Perl 5-ish
%a = (%b.str => %c); # Perl 6 equiv.
> %d = (@e, @f);
%d = (stringify(\@e) => \@f); # Perl 5-ish
On 5/4/01 11:47 PM, Edward Peschko wrote:
> Horrors is right. The default perl5 behaviour is *useful*. I use the
> %b=(%a,%c)
> metaphor all of the time.
I believe you can get the Perl 5 functionality by throwing a few *
characters in there somewhere...
> Why not just keep it simple?
Based on A
On 5/5/01 12:06 AM, Nathan Wiger wrote:
> Maybe we need a way to say "flatten these together".
> I'm going to throw out a new ":" op here:
[snip]
> Hmmm... I kinda like that... Am I missing anything?
Maybe the fact that Larry's already claimed the colon? :)
-John
As a . doubter form the earlier threads, I'd just like to say that Apoc. 2
has gone a long way towards making me feel better about . as the method call
thingie...both by explaining all the neat things . does in Perl 6, and by
avoiding the potentially distressing introduction of the replacement str
I know I'm jumping ahead, but here goes...
Built-in classes in Perl 5 and 6 are uppercase: UNIVERSAL, ARRAY, HASH, etc.
By convention, "user" classes are Title::Cased. Simple guideline: don't use
UPPERCASE class names or risk being squished by a later revision of Perl.
Method names *sort of* fo
On 5/5/01 3:28 PM, Larry Wall wrote:
> I expect the real choice is between <$FOO and <$FOO>. I can convince
> myself pretty easily that a unary < is just another name for "next", or
> "more", or something.
Yeah, but it looks like "previous"! ;)
> maybe I should hold out for «» meaning qw() even
On 7/21/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> Have at it...
The only thing I immediately don't like is the use of the normal identifier
character "_" to indicate the "specialness" of a particular variable (or
attribute or whatever we're calling them these days). IMO, a "_" should
just be a
On 7/21/05 8:14 PM, Larry Wall wrote:
> On Thu, Jul 21, 2005 at 03:25:17PM -0400, John Siracusa wrote:
>> The only thing I immediately don't like is the use of the normal identifier
>> character "_" to indicate the "specialness" of a particular variable (o
On 7/22/05 11:37 AM, Larry Wall wrote:
> The problem I have with "is private" is that, while there may very
> well be a trait of that name that you can interrogate, I really
> want people to think of the private methods as being in a different
> namespace so that there's no confusion about the fact
Ack, I screwed up that last email with some bad copy and paste. Ignore it
in favor of this one please :)
---
On 7/22/05 11:37 AM, Larry Wall wrote:
> The problem I have with "is private" is that, while there may very
> well be a trait of that name that you can interrogate, I really
> want people
Third time's the charm...really. Please ignore the last two messages from
me in favor of this one please. Sigh**2.
---
On 7/22/05 11:37 AM, Larry Wall wrote:
> The problem I have with "is private" is that, while there may very
> well be a trait of that name that you can interrogate, I really
>
On 8/16/05, Tim Bunce <[EMAIL PROTECTED]> wrote:
> I was a little dissapointed that there wasn't greater focus on using
> Perl6 features - especially as it would have helped kick-start my own
> understanding of Perl6 topics that I expect to be significant (such as
> Roles and Pairs, to pick two at
On 8/17/05 5:39 AM, Tim Bunce wrote:
> On Tue, Aug 16, 2005 at 03:58:54PM -0400, John Siracusa wrote:
>> I think it'll take years, and much actual production experience building
>> Perl 6 modules before the community learns what works and what doesn't for a
>> Perl
On 10/20/05 10:56 AM, Larry Wall wrote:
> I don't know how long this EuroOSCON net is going to stay up, so I'll be
> brief. I think we're having a new "class" sigil. Where we've been
> writing ::T, that will revert to meaning "an existing class T that
> we just might not see the declaration of fo
On 10/20/05 11:37 AM, Larry Wall wrote:
> On Thu, Oct 20, 2005 at 10:32:14AM -0500, Steve Peters wrote:
> : The idea of punishing programmers who choose to use certain operating system
> : or locales just doesn't seem right to me.
>
> That's why we provide ugly ASCII workarounds for all of them.
On 10/26/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> A mandatory named parameter is now marked +:$nonoptionaloption.
Woo! :)
-John
On 1/18/06 11:06 PM, Rob Kinyon wrote:
> Not to mention that 90% of the hacking done in Class:: and Object:: will
> handled by the fact that Perl6 has actual OO syntax. ("Look Ma, no hands!")
> You won't need Class::MakeMethods because Perl6 will make your accessors for
> you.
There's more to life
On 4/8/06 6:29 AM, Damian Conway wrote:
> I'm not enamoured of the .# I must confess. Nor of the #. either.
Thank goodness...I was beginning to think it was only me!
> Though, frankly, every one of the alternatives proposed so far is so ugly that
> I seriously doubt that anyone will actually want
On 4/10/06 8:38 PM, Larry Wall wrote:
> Even better is:
>
> =begin UNUSED
> sub foo
> {
> if foo { }
> }
> =end UNUSED
>
> And I don't really care if that's not what people are used to.
> The whole point of Perl 6 is to change How Things Work.
Do you care that it's hard
On 4/10/06 9:11 PM, Larry Wall wrote:
> I think commenting out code with # is sufficiently antisocial that
> you should probably do it with .
What's antisocial about it? What's the alternative for quickly commenting
out a few lines? Braced #[ ... ]# pairs are not as easy to "mindlessly"
On 4/30/06 7:44 AM, Juerd wrote:
> Jonathan Lang skribis 2006-04-29 19:08 (-0700):
>> Is there a reason that we've been insisting that a long dot should use
>> whitespace as filling?
>
> I don't know.
>
>> foo.___.bar
>
> Would still have the problem of clashing with .. when there's no _ i
On 12/21/07 5:54 AM, Larry Wall wrote:
> To you and me, the fact that there are single quotes means there's
> something there to hide. But other people think the other way and
> see double quotes as indicating there's something to interpolate.
> I think PBP comes down on that side, but to me, sing
Forgive me if this is a question the reveals how poorly I've been
following Perl 6 development, but what's the deal with some methods
using hyphen-separated words (e.g., day-of-week) while others use
"normal" Perl method names (e.g., set_second)?
-John
On Sat, Apr 10, 2010 at 6:14 AM, Mark J. Reed wrote:
> I'd much rather see a single consistent style throughout
Yeah, that's was my main point/question. I wanted to know if it was
it some intentional convention (e.g., "all methods that change the
object state use hyphens, and all others use unde
On Sat, Apr 10, 2010 at 5:25 PM, Damian Conway wrote:
> Personally, I'd prefer to see the English conventions carried over to
> the use of general use of hyphen and underscore in identifiers in
> the core (and everywhere else).
That's certainly an example of how hyphens might gain meaning in Perl
On Sat, Apr 10, 2010 at 7:17 PM, Damian Conway wrote:
> And is it really so hard to teach: "use underscore by default and reserve
> hyphens for between a noun and its adjective"? Perhaps it *is*, but
> then that's a very sad reflection on our profession.
I'm not sure if the intersection of people
On Sat, Apr 10, 2010 at 8:23 PM, Daniel Ruoso wrote:
> Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu:
>> I'm having trouble imaging any convention that involves mixing word
>> separators being successful.
>
> But the convention Damian is proposing
On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway wrote:
> Hyphen/underscore equivalence would allow those (apparently elite few) who
> can correctly use a hyphen to correctly use the hyphen
That's about the only advantage of this scheme that I can think of.
The disadvantages, which affect everyone
From an old summary:
http://www.perl.com/pub/a/2003/04/p6pdigest/20030427.html?page=2
> Paul Hodges took a crack at implementing for as a subroutine and came
up with
> something that didn't look too insane. Luke Palmer added a refinement
allowing
> for n at a time looping. However, for reasons
On Thursday, July 31, 2003, at 12:05 PM, Luke Palmer wrote:
Well, I don't think it's possible, actually. There's a flattening
list context at the beginning (implying a sugary drink from 7 eleven),
followed by a code block. But, as we know, slurpy arrays can only
come at the end of positional para
On 8/1/03 11:44 AM, Mark J. Reed wrote:
> Is it possible with the new parameter declaration syntax to declare
> a mandatory name-only parameter?
My earlier plea for this feature begins here:
http://archive.develooper.com/[EMAIL PROTECTED]/msg14666.html
I didn't think I made much headway, but thi
On 1/5/04 1:55 PM, Lars Balker Rasmussen wrote:
> The Perl 6 Summarizer <[EMAIL PROTECTED]> writes:
>> I confess I wouldn't be surprised if, by the end of the year, we haven't seen
>> the full implementation of at least one of the big non-Perl scripting
>> languages on top of Parrot.
>
> I'm confu
On 3/11/04 4:04 PM, Larry Wall wrote:
> On Thu, Mar 11, 2004 at 12:43:22PM -0800, Larry Wall wrote:
> : Which is precisely the problem with something like
> :
> : $a cmp= $b
> :
> : insofar as $a is being treated as a string at one moment and as a boolean
> : at the next.
>
> Well, okay, not
On 3/12/04 12:43 PM, Larry Wall wrote:
> Some good questions only have bad answers. This might be one of them.
I have been watching this thread with increasing unease, asking myself
exactly what the potential benefit is of this proposed feature and syntax.
I'm all for saving some typing, but yees
On 4/17/04 6:22 AM, Piers Cawley wrote:
> chromatic <[EMAIL PROTECTED]> writes:
>> Warning -- 20 pages, the first of which is a table of contents.
>
> But it's all excellent good stuff. Well done Larry and Co. Now, if you
> could all just hold off with the questions 'til Monday you'll make a
> sum
Those with encyclopedic knowledge of the perl6-language list will recall my
impassioned, but ultimately futile plea for required named parameters--that
is, required arguments to a function that must be supplied as "pairs" rather
than positionally.
Here's a post from the middle of that old thread:
On 4/19/04 11:11 AM, Larry Wall wrote:
> On Sat, Apr 17, 2004 at 01:12:58PM -0400, Austin Hastings wrote:
> : If it's not totally obvious to everyone, you should download a copy of A12
> : (I like the "printer-friendly" all-in-one-page version) as a hedge against
> : the almost-inevitable slashdott
On 4/19/04 1:30 PM, Larry Wall wrote:
> On Mon, Apr 19, 2004 at 01:14:57PM -0400, John Siracusa wrote:
> : I know we are running out of special characters, but I really, really think
> : that required named parameters are a natural fit for many common APIs. A12
> : has reinforced
On 4/19/04 1:41 PM, Dan Sugalski wrote:
> At 1:14 PM -0400 4/19/04, John Siracusa wrote:
>> I know we are running out of special characters, but I really, really think
>> that required named parameters are a natural fit for many common APIs.
>
> Well... maybe, but ponder
>From page 7:
> In any event, strings are reserved for other object layouts. We could
> conceivably have things like:
>
>return $class.bless("Cstruct", *%_);
>
> So as it happens, 0 is short for the layout "P6opaque".
I feel like "we" have pretty well staked out the letters p-e-r-l, but
anyth
Let's say I have a class with some attributes:
class Dog;
has $.name is rw;
has $.age is rw;
has $.gender is rw;
I initially decide to accept the default accessors.
$dog.name = 'Ralph';
print $dog.age;
This works well for a while, but then I decide to update Dog so that
On 4/19/04 3:36 PM, Larry Wall wrote:
> On Mon, Apr 19, 2004 at 02:04:55PM -0400, John Siracusa wrote:
> : So, how about "Perl6opaque" (or "Perl6Opaque"), just to be safe :)
>
> How 'bout just "Opaque", meaning Parrot's native object type, or w
On 4/19/04 3:58 PM, Austin Hastings wrote:
>> I initially decide to accept the default accessors.
>>
>> $dog.name = 'Ralph';
>> print $dog.age;
>>
>> This works well for a while, but then I decide to update Dog so that setting
>> the name also sets the gender.
>>
>> $dog.name = 'Susi
On 4/19/04 4:47 PM, [EMAIL PROTECTED] wrote:
>> On 4/19/04 3:58 PM, Austin Hastings wrote:
>> One work-around might be an alternate kind of default accessor that doesn't
>> allow assignment:
>>
>> $dog.name # get
>> $dog.name('foo') # set
>> $dog.name = 'foo' # compile-time er
On 4/19/04 7:16 PM, Larry Wall wrote:
> On Mon, Apr 19, 2004 at 01:44:53PM -0400, John Siracusa wrote:
> : ...named and required, or named and optional? IOW, is this all true?
> :
> : sub foo(+$a, +$b) { ... }
> :
> : foo(); # compile-time error
On 4/19/04 7:20 PM, Larry Wall wrote:
> On Mon, Apr 19, 2004 at 06:53:29PM -0400, John Siracusa wrote:
> : Yeah, that's exactly what I don't want to type over and over :)
>
> I really don't understand what you're getting at here. First you
> complain that yo
On 4/19/04 9:05 PM, Damian Conway wrote:
> You want:
>
> sub foo(+$a is required, +$b is required) { ... }
Yes, that would be just fine :)
-John
On 4/19/04 10:04 PM, Damian Conway wrote:
> John Siracusa wrote:
>> I'd either like a way to more cleanly extend the default accessor's
>> assignment behavior down the road (i.e. by just writing a new name() method,
>> not by hacking away at STORE traits and addin
On 4/20/04 1:25 AM, Luke Palmer wrote:
> John Siracusa writes:
>> The "will STORE" stuff covers the easy cases, but can I extend it all the
>> way up to a name() that's a multimethod with a ton of optional args? I
>> supposed you can (technically) do all of tha
On 4/20/04 10:42 AM, Dan Sugalski wrote:
> At 9:50 AM -0400 4/20/04, John Siracusa wrote:
>> On 4/19/04 7:16 PM, Larry Wall wrote:
>>> Well, no, we're still stuck at run-time validation of that. In the case
>>> of methods you can't really do anything else a
On 4/20/04 12:14 PM, Luke Palmer wrote:
> Okay, well, I thought that my example did that, but apparently using
> C and C is a little too complex... (my sentiments
> are beginning to follow Larry's, in that I'm not sure you know what you
> want -- perhaps you could give a hypotheical syntax?)
There
On 4/20/04 2:37 PM, Larry Wall wrote:
> On Tue, Apr 20, 2004 at 01:15:24PM -0400, John Siracusa wrote:
> : With that "has" line alone, you auto-magically get an accessor that works
> : like this:
> :
> : $obj.foo# get value of $.foo
> : $obj.foo(5) # set
On 4/20/04 4:08 PM, Aaron Sherman wrote:
> On Tue, 2004-04-20 at 15:40, John Siracusa wrote:
>> On 4/20/04 2:37 PM, Larry Wall wrote:
>>> It's wrong to introduce a fundamental asymmetry that breaks the contract
>>> that an accessor can be used as a variable.
>
On 4/22/04 5:33 PM, Aaron Sherman wrote:
> On Tue, 2004-04-20 at 10:51, John Siracusa wrote:
>> Hm, so how would the "is required" trait that Damian posted work? Would it
>> simply be shorthand for a run-time check that I don't have to write myself?
>> I wa
On 4/22/04 6:52 PM, John Siracusa wrote:
> Yes, it appears that runtime checks for the existence of required params
> will continue to be a necessary part of Perl programming.
...of course, there are at least two ways to do "runtime checks":
* runtime checks that the program
Based on the "default accessors and encapsulation" thread, it seems like a
Perl 6 equivalent of Class::MethodMaker will be still be useful in our (or
at least "my") Brave New World. I've been pondering the best way to create
such a beast in Perl 6.
The most common two Perl 5 techniques are:
1. U
>From the recent P6 Summary:
> Larry's response is a masterpiece of conciseness:
>
> Well, actually, we saved you last summer when we decided to make +
> mean that the parameter must be named.
Larry's response also didn't really address the issue, since parameters
marked with a + in t
On 5/5/04 6:24 PM, Austin Hastings wrote:
> To answer Dan's posting: I fully expect to never use any of these
> sigils, myself. I'm sure there will be traits for this- nice
> verbose traits. (Signatures are about as write-once as you can get...)
>
> method x(
> requires:invocant $me,
> require
On 8/20/04 5:30 PM, Austin Hastings wrote:
> How about "scalar"? The fact that one person, one time, came up with a
> need to invoke it doesn't mean we have to race it up the huffman tree.
> P6 is winning the DWIM race most of the time contextually. Maybe [#] as
> a macro, if you like.
Yeah, that'
Synopsis 4 says:
"PRE and POST must return boolean values that are evaluated according to the
usual Design by Contract rules."
Do "the usual Design by Contract rules" include the ability to "turn off"
(i.e. remove from program flow) PRE and POST blocks for performance reasons
in production, or is
On 9/3/04 6:03 PM, Larry Wall wrote:
> On Fri, Sep 03, 2004 at 04:35:56PM -0400, John Siracusa wrote:
> : Synopsis 4 says:
> :
> : "PRE and POST must return boolean values that are evaluated according to the
> : usual Design by Contract rules."
> :
> : Do &quo
On 9/3/04 6:45 PM, Damian Conway wrote:
> John Siracusa wrote:
>>> I don't see how we could prevent someone from clobbering the global
>>> definitions of PRE and POST to be no-ops if they wanted to. Seems to
>>> me that the whole point of putting the program i
On 9/4/04 5:38 PM, Larry Wall wrote:
> On Sat, Sep 04, 2004 at 08:17:36PM +0100, Piers Cawley wrote:
> : John Siracusa <[EMAIL PROTECTED]> writes:
> : > Ah ha, I didn't realize macros could override/replace existing control
> : > structures. Okay, ship it! :)
>
On 9/4/04 6:58 PM, Nicholas Clark wrote:
> On Sat, Sep 04, 2004 at 05:59:18PM -0400, John Siracusa wrote:
>> Anyway, it'd be nice if Perl 6 supported some sort of equivalent to Mac OS
>> X's application wrappers: a dir tree containing all the files needed to run
>> Y
On 9/4/04 7:31 PM, Simon Cozens wrote:
> [EMAIL PROTECTED] (John Siracusa) writes:
>> Anyway, what it'll give me is "official" support for this type of thing.
>
> Call me a crazy man, but I *like* the lack of official support.
>
> I actually count it as a Go
On 9/4/04 11:42 PM, chromatic wrote:
> On Sat, 2004-09-04 at 18:44, John Siracusa wrote:
>> To bring it home, I think packaging and distribution is important enough to
>> warrant a standard, core-supported implementation.
>
>> I think the "specially structured dir
On 9/5/04 8:31 PM, Luke Palmer wrote:
> John Siracusa writes:
>> I think the most important question was at the end of my last message:
>> is something even *possible* without core support? Taking a set of
>> scripts and libs and making single-file, compiled (or "p
On 9/6/04 3:48 AM, Simon Cozens wrote:
> [EMAIL PROTECTED] (John Siracusa) writes:
>> PAR doesn't compile or precompile to bytecode, it packages, temp-expands,
>> and runs.
>
> It *could* do this, but loading bytecode in Perl 5 is slower than loading
> and compiling
On 9/6/04 12:13 PM, Nicholas Clark wrote:
> On Sat, Sep 04, 2004 at 09:44:54PM -0400, John Siracusa wrote:
>> Finally, platform independent execution of any packaged or precompiled
>> single file will *require* cooperation (core support) from the perl
>> executable itself.
On 9/6/04 12:21 PM, Nicholas Clark wrote:
>> I think packaging has the same characteristics. But unlike CPAN, packaging
>> does require some minimum amount of core support to meet what I consider to
>> be the minimum standard of elegance.
>
> I think that this is true. I'm not sure what the minim
> An interpolated array:
>
> / @cmds /
>
> is matched as if it were an alternation of its elements:
>
> / [ @cmds[0] | @cmds[1] | @cmds[2] | ... ] /
>
> As with a scalar variable, each one is matched as a literal.
Like this? (Assuming single quotes don't interpolate @foo[...])
@a
On 11/30/04 6:35 PM, James Mastros wrote:
> Austin Hastings wrote:
>> Larry Wall wrote:
>>>* We get the cute, clean and rather more typeable
>>>
>>> $var[3]
"Cute" maybe (looks like a chain of fish)
> The problem with {} for a hash dereference operator is not it's
> typeablility, but rat
On 11/30/04 9:54 PM, Matt Diephouse wrote:
> use CGI «:standard»;
> [...]
> use CGi <:standard>;
Who is doing this? I'm just saying...
use CGI ':standard';
It really ain't all that broke, is it?
-John
On Wed, 01 Dec 2004 07:41:18 GMT, Smylers <[EMAIL PROTECTED]> wrote:
> John Siracusa writes:
>
> > Call me crazy, but at this point I'm prone to stick with what I've done in
> > Perl 5 for years:
> >
> > $var{'key1'}{'key2'
>From http://dirtsimple.org/2004/12/python-is-not-java.html
"In Java, you have to use getters and setters because using public fields
gives you no opportunity to go back and change your mind later to using
getters and setters. So in Java, you might as well get the chore out of the
way up front. In
On Fri, 3 Dec 2004 20:37:40 +0100, Juerd <[EMAIL PROTECTED]> wrote:
> John Siracusa skribis 2004-12-03 14:05 (-0500):
>> From http://dirtsimple.org/2004/12/python-is-not-java.html
>>
>> "In Java, you have to use getters and setters because using public fields
&
On Fri, 3 Dec 2004 22:06:43 +0100, Paul Johnson <[EMAIL PROTECTED]> wrote:
> http://www.nntp.perl.org/group/perl.perl6.language/9576
Wow, that's a blast from the past. I wonder how much of it is still
valid... :)
-John
On 3/18/05 12:18 AM, Larry Wall wrote:
> Autochomping is one of the motivations for switching from "while" to
> "for" for the normal line input method, since "while" might think a
> blank line is false, while "for" only cares whether the next value
> is defined.
Speaking of which (ha), does that m
On 6/16/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> And I think that subs and methods *should* complain about all unused
> non-optional parameters *except* invocants.
This brings up something I've been thinking about. I sometimes write a
method in Perl 5 that does something or other and then c
On 6/17/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 16, 2005 at 05:18:51PM -0400, John Siracusa wrote:
> : Now in Perl 6 I'll want to use fancy named parameters and so on, but I don't
> : want to lose the abilities described above. How would those examples lo
On 6/17/05 6:18 PM, Damian Conway wrote:
> John Siracusa wrote:
>> (BTW, I'm not sure where those "./" thingies came from, but it's what GMail
>> showed in your message. I'm assuming it should just be ".")
>
> No. There's now also
(Yes, the subject line is a ps joke...it's late...well, late for a new
parent, anyway.)
On 6/17/05 6:18 PM, Damian Conway wrote:
> John Siracusa wrote:
>> (BTW, I'm not sure where those "./" thingies came from, but it's what GMail
>> showed in your
Oops, part of Diamian's quoted text got trimmed accidentally in my last
post. It should have looked like this:
On 6/17/05 10:42 PM, John Siracusa wrote:
> [...] I'm not, however, buying Damian's argument here:
>
> On 2005-05-15 20:33:19, [EMAIL PROTECTED] (Damian Conwa
On 6/17/05 10:56 PM, David Storrs wrote:
> I'm not fond of .:: because I don't think it's sufficiently visually
> distinct from .:.
Hm, let's look at it:
method total(...)
{
.::sanity_check();
return .:value_one() + .:value_two();
}
Maybe lined up?
.::internal_value(
On 6/18/05 12:23 AM, Adam Kennedy wrote:
> The reason we ended up at ./method was simply because it was the best
> suggestion anyone had.
That's what I'm trying to remedy :)
> It's other advantage is that (except for on nordic keyboards) dot and
> slash are generally right next to each other, so
1 - 100 of 177 matches
Mail list logo
