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/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 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
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 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 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 mean we can
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
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 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'}[3]{'key3'}
In which case do that, since it'll still work in Perl 6
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
$varkey1key2[3]key3
Cute maybe (looks like a chain of fish)
The problem with {} for a hash dereference operator is not it's
typeablility, but rather
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
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 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/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 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: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 you'd rather write an ordinary method
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 adding private worker subs) or a way
to auto
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 12:14 PM, Luke Palmer wrote:
Okay, well, I thought that my example did that, but apparently using
Cwill get and Cwill set 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
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 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 slashdotting.
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
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 a likely common case
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
anything else is
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/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
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 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
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
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
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 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/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 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
On 12/6/02 4:41 PM, Michael Lazzaro wrote:
my PersonName $name = .new(...);
my FormalStr $s = $name;# Dr. William P. Smith
my InformalStr $s = $name;# Bill
Whether that is good, bad, or indifferent I leave to the OO Police.
I'm not even deputized, but I call foul: excessive use
On 10/31/02 5:33 PM, [EMAIL PROTECTED] wrote:
Damian Conway writes:
BTW, Both Larry and I do understand the appeal of interleaving
sources and iterators. We did consider it at some length back
in January, when we spent a week thrashing this syntax out.
Of course, I can't speak for Larry,
On 10/26/02 7:24 PM, Simon Cozens wrote:
To the innocent bystanders, I hope you're not buying any of this crap
about Perl 6 being more regular or removing the inconsistencies of
Perl 5. It simply isn't true.
I was buying that right up until about a week or two ago when Larry emerged
from his
On 10/26/02 8:18 PM, Larry Wall wrote:
On 27 Oct 2002, Simon Cozens wrote:
: To the innocent bystanders,
I'm afraid you're preaching to the null set here. :-)
I don't know whether to be flattered that you think I'm not just a
bystander, or insulted that you think I'm not innocent ;)
-John
On 6/18/02 6:10 PM, Damian Conway wrote:
Larry has previously mentioned the prospect of Perl 6 module names being
extended to include version number and author.
If this were to be done, would seem reasonable for the author component to
simply be the author's CPAN username. These are
On 6/18/02 8:32 PM, Larry Wall wrote:
I expect to end up with a multi-level system, where you can use anything from
a DNS name (guaranteed to contain dots) through author IDs (no dots) to
blessed top-level names for universally acclaimed modules, for some definition
of universal.
I'm not
On 6/16/02 1:50 AM, Luke Palmer wrote:
On Sun, 16 Jun 2002, Michael G Schwern wrote:
Let's dump out the sack of namespace partitioning problems:
What if Acme decides it wants to release part of it's code as Open Source?
(Happens a lot). Does it release it as Com::Acme::Text::Thing or
Once nice thing about Java is the class naming convention that lets
individual companies (or even individuals, I guess) do custom development
that they can safely integrate with the standard Java classes and the work
of other companies/individuals without fear of namespace clashes. For
example,
On 6/7/02 4:48 PM, Luke Palmer wrote:
rule tag($name) {:w \ $name %opts:=[ (\S+)=(\S+) ]* \ }
Then, you can match an img tag with:
/ tag 'img' /
See, isn't that great?
Don't you mean, see, isn't that massively over-simplified? ;)
(but yeah, we get the idea... :)
-John
On 6/7/02 4:51 PM, Damian Conway wrote:
I have no doubt that, once Perl 6 is available, we'll see a rash of modules
released in the Grammar:: namespace. Including Grammar::HTML and Grammar::XML.
Why not just make Grammar::DTD, and then make Grammar::Generator::FromDTD.
Then use those to make
On 6/7/02 5:44 PM, Damian Conway wrote:
John Siracusa wrote:
I have no doubt that, once Perl 6 is available, we'll see a rash of modules
released in the Grammar:: namespace. Including Grammar::HTML and
Grammar::XML.
Why not just make Grammar::DTD, and then make Grammar::Generator::FromDTD
1 - 100 of 154 matches
Mail list logo
