On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway dam...@conway.org 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
On Sat, Apr 10, 2010 at 6:14 AM, Mark J. Reed markjr...@gmail.com 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
On Sat, Apr 10, 2010 at 5:25 PM, Damian Conway dam...@conway.org 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
On Sat, Apr 10, 2010 at 7:17 PM, Damian Conway dam...@conway.org 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
On Sat, Apr 10, 2010 at 8:23 PM, Daniel Ruoso dan...@ruoso.com 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 is simply use underscores
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, single
On 4/24/07 6:31 PM, Nikolay Ananiev wrote:
As we all know, parrot has been in development for 7 years now. That's a lot
of time and many things have changed since then. From my point of view one of
the biggest strengths of Parrot is that it's a target for many (and why not
all?) dynamic
On 8/23/06 4:09 PM, Aaron Sherman wrote:
here's the problem with that: llvm is a very light layer, but it's yet another
layer. To put it between parrot and hardware would mean that parrot is JITing
to LLVM byte-code, which is JITing to machine code. Not really ideal.
...unless LLVM does a much
Has anyone looked at LLVM lately?
http://llvm.org/
It seems to be making a lot of progress lately with the support of Apple
(which is using LLVM for its own purposes in Mac OS X). Is there anything
there Parrot can steal? Would it make sense for Parrot to target LLVM
bytecode and let LLVM do
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 _ in
between.
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 harder to
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/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 than
On 10/26/05, Larry Wall [EMAIL PROTECTED] wrote:
A mandatory named parameter is now marked +:$nonoptionaloption.
Woo! :)
-John
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 for
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. We
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 6 API (let alone implementation). So
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 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 that
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 to
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
want
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 _ no
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 (or
attribute or whatever we're calling them
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 the
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 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
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() ./:method() # worst
Why exactly is the slash
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: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 with a
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 look
: in native Perl 6 code
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 a unary ./ operator in Perl 6.
Unary . calls a specified method
(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 message. I'm assuming it should just
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 Conway) said:
This missing
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?
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
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
gives you no opportunity to go back and change
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 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/24/04 7:27 PM, Tim Bunce wrote:
I predict a burst of wild creativity from authors enjoying the
exploration of all the wonderful tools in the perl6 toolbox.
Then, after a year or three of fun, sawn off limbs, and bloodied
fingers (and after a few good books get published) most of us
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 = ('a',
On Wed, 8 Sep 2004 15:46:17 +, Herbert Snorrason [EMAIL PROTECTED] wrote:
I suggest we institute a Rule One for Dan. (And number two, too,
while we're at it.) It'd be easier that way.
That rule already exists, but I think Dan still feels insecure about
it ;) The Larry Way(tm) is to include
over. (Maybe
John Siracusa will be willing to look it over before I post it; he is
good with this kind of stuff.)
I just want to make sure that people are thinking about it on all levels,
not just the Parrot level. An ideal solution spans all levels.
Unfortunately, in the absence of a design
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 source, so there's not really much
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. PAR is neat, but it doesn't
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 minimal list
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 of files and its single-file packaged
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 precompiled
bytecode or whatever
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! :)
:
: They'd be no fun if they couldn't
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
Your Wonderful Perl Program
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 Good Thing that perl can be made to do cool stuff
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 than
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 the usual Design by Contract rules include
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 in charge of its own
compilation is to let
On Wed, 25 Aug 2004 07:48:03 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote:
John Siracusa [EMAIL PROTECTED] wrote:
On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski [EMAIL PROTECTED] wrote:
The big question is whether being clever and producing the tightest
type is worth the time to figure
On Thu, 26 Aug 2004 11:10:59 -0400, Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:56 AM -0400 8/26/04, John Siracusa wrote:
Why make a stop in 32-bit land at all in that case? If the system supports
64-bit ints, why not use them for everything right up until you promote to
BigNum
On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski [EMAIL PROTECTED] wrote:
The big question is whether being clever and producing the tightest
type is worth the time to figure out what that type is, as well as
the potentially uncertain output type.
Tangentially related: will promotion be
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's my
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,
requires
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 the
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. Use
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 was under the impression that it would work the way
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 programmer has to write
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!
: foo(1, 2); # compile-time
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/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 that with will STORE, but it
seems an odd place
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 anyway, generally speaking.
Why
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 $.foo = 5
I don't care what
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.
Er, I think we have different definitions
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 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 that belief. Save
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
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 whatever
the native opaque type is for the platform in question
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 = 'Susie'; # also sets
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 error
I
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
summary
On 3/24/04 1:58 PM, Brent 'Dax' Royal-Gordon wrote:
And I do think URIs aren't a horrible idea, although it doesn't matter
since you disagree. Ah well...
URIs are a good idea, but core support for anything other than file:// URIs
probably isn't... :) Anyway, if you use URIs, then you can be
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 a
On 3/4/04 5:09 PM, Dan Sugalski wrote:
If the local system returns localtime, I can see adjusting to GMT or UTC, or
whatever, as that ought to be a trivial transform.
Er, I'm not so sure about that. That means you'd have to be 100% sure that
you can determine the local timezone without any
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 confused, are
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
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's no slower than Perl 5, but we'd like to do
better
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
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) is off {
print STDERR $msg;
}
some
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
of the spiritual equivalent of #ifdef
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 Cdebug is in the example above) causes the immediate sub call to be
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
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 guessing
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 global
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-UNIVERSAL::id;
If you wish to be precise, yes
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/attribute should have a name that reflects
the relative rarity of its use
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.) If
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 must now have
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.*id ==
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 the
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:
[...]
If memory addresses can change over time, then we
On 12/11/02 1:10 PM, Michael Lazzaro wrote:
I doggishly maintain my preference for treating stringification for
output and stringification for debugging differently, but as long as
I can specify an AS_STRING (sp?) method for a class, and _still_ get
at a debugging version to print to other
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 Cid method is *for*.
I must have missed this (or forgotten it?) Any chance of it becoming .ID or
.oid or even ._id? I'm
1 - 100 of 187 matches
Mail list logo
