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
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 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 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 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
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 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
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 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/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/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 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 10/26/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> A mandatory named parameter is now marked +:$nonoptionaloption.
Woo! :)
-John
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/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 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 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
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
>
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
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
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/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 6/18/05 8:55 PM, Juerd wrote:
>> I'm just hoping there's an alternative that everyone will like better
>
> As long as I'm part of "everyone", that won't happen. I've listed
> numerous possibilities for myself, and found none that I liked better
> than ./method. I don't think you can come up wit
On 6/18/05 8:28 PM, Juerd wrote:
> The unix shell and things resembling it will still be in use much fifteen
> years after today, Perl 5 will not.
Ooo, a bold prediction :)
-John
On 6/18/05 8:11 PM, Juerd wrote:
> John Siracusa skribis 2005-06-18 19:55 (-0400):
>> ./method() ./:method()
>> [EMAIL PROTECTED]() .@:method()
>> .>method() .>:method()
>> .-method() .-:method()
> [...]
>> ./method() .
On 6/18/05 7:54 PM, Juerd wrote:
>
>> [EMAIL PROTECTED]() .@:method()
>
> In Perl, @ has a VERY strong association with arrays, so except for
> specialised frameworks, I recommend against using it for other purposes.
The / character has very strong associations in nearly every programming
l
On 6/18/05 2:40 PM, Darren Duncan wrote:
> As I recall, it was decided for a broad scope that public and private
> item invocation syntax was exactly the same but with the
> consideration that all private items have a ':' as the first
> character in their otherwise alphanumeric names (the ':' looks
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
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(
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
(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
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
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/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 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 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 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
&
>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 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'
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 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
> 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 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
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 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/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/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/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 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 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/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/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
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 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'
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
>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
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
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
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/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/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 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 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 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/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/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 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 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 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 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 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
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
>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
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
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 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
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/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
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 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 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 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 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
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 3/12/03 1:50 AM, Mark Biggar wrote:
> John Siracusa wrote:
>>> From A6:
>>> I worry that generalized wrappers will make it impossible to compile fast
>>> subroutine calls, if we always have to allow for run-time insertion of
>>> handlers. Of course, that
>From A6:
> I worry that generalized wrappers will make it impossible to compile fast
> subroutine calls, if we always have to allow for run-time insertion of
> handlers. Of course, that's no slower than Perl 5, but we'd like to do better
> than Perl 5. Perhaps we can have the default be to have wr
On 1/10/03 12:24 PM, Damian Conway wrote:
> "Immediate" subroutines are executed as soon as they are parsed (i.e. they're
> like named BEGIN blocks).
>
> Returning a closure/block from an immediate sub called in a void context
> (as C is in the example above) causes the immediate sub call to be
>
On 1/10/03 11:11 AM, Dan Brook wrote:
> On Thu, 09 Jan 2003 19:55:20 -0500
> John Siracusa <[EMAIL PROTECTED]> wrote:
>> Has there been any discussion of how to create code in Perl 6 that's
>> there under some conditions, but not there under others? I'm thinking
On 1/9/03 11:27 PM, Michael G Schwern wrote:
> On Thu, Jan 09, 2003 at 11:15:49PM -0500, John Siracusa wrote:
>> On 1/9/03 10:10 PM, Michael G Schwern wrote:
>>> I would assume it to be a compiler hint via subroutine attribute.
>>>
>>> sub debug ($msg
On 1/9/03 10:10 PM, Michael G Schwern wrote:
> I would assume it to be a compiler hint via subroutine attribute.
>
> sub debug ($msg) is off {
> print STDERR $msg;
> }
>
> some "this subroutine is a no-op if a flag is set" attribute.
Hm, not quite as convenient as setting a package globa
On 1/9/03 9:01 PM, Luke Palmer wrote:
> Well, I just do:
>
> sub debug {
> print STDERR shift, "\n" if DEBUG;
> }
>
> And hopefully (I don't know P5 internals so well) that optimizes to a
> no-op so there's not even a function call there.
I don't know P5 internals so well either, but I'm guess
Has there been any discussion of how to create code in Perl 6 that's there
under some conditions, but not there under others? I'm thinking of the
spiritual equivalent of #ifdef, only Perlish.
In Perl 5, there were many attempts to use such a feature for debugging and
assertions. What everyone wa
On 12/13/02 12:44 PM, Michael Lazzaro wrote:
> On Thursday, December 12, 2002, at 06:55 PM, James Mastros wrote:
>> And I'd say (but who asked me -- IMHO, of course) that it should be
>> perfectly valid to write code like the above. (That IDs should be
>> unique across a process over all time.)
On 12/13/02 10:49 AM, Garrett Goebel wrote:
> John Siracusa wrote:
>> Using the method/attribute named "id" for "this is
>> the same object" comparisons is just plain bad
>> Huffman coding. The "this is the same object"
>> method/attribut
On 12/13/02 5:09 AM, Luke Palmer wrote:
>> From: John Siracusa <[EMAIL PROTECTED]>
>> On 12/12/02 4:01 PM, Larry Wall wrote:
>>> On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
>>> : So we'll _have_ to write $obj.*id when we mean $obj-&
On 12/12/02 4:41 PM, Dave Whipp wrote:
> "John Siracusa" <[EMAIL PROTECTED]> wrote:
>> memory addresses is so infrequent that warrants a much
>> less common and/or longer method name than "id".
>
> Another reason for not making these synonymous:
&
On 12/12/02 4:01 PM, Larry Wall wrote:
> On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
> : So we'll _have_ to write $obj.*id when we mean $obj->UNIVERSAL::id;
>
> If you wish to be precise, yes. But $a.id eq $b.id should work for most any
> class that uses the the term "id" in t
On 12/12/02 12:55 PM, Larry Wall wrote:
> As for namespace pollution and classes that use .id in Perl 5, I
> don't think it's going to be a big problem. Built-in identifiers
> do not have a required prefix, but they have an optional prefix,
> which is C<*>. I think we can probably parse
>
> $a
On 12/11/02 11:41 PM, Luke Palmer wrote:
>> More generally, I really don't want to have too many (any?) "system" object
>> method names squatting in "my" all-lowercase object method namespace. It's
>> not hard to think of many kinds of objects that would naturally have an "id"
>> attribute, but mu
On 12/11/02 6:16 PM, Damian Conway wrote:
> There's no need for special methods or (gods forbid) more operators.
> Just:
>
>$obj1.id == $obj2.id
>
> That's what the universal C method is *for*.
I must have missed this (or forgotten it?) Any chance of it becoming .ID or
.oid or even ._id? I
1 - 100 of 177 matches
Mail list logo
