On 09/14/2018 04:33 PM, Ralph Mellor wrote:
multi method kv ...
Use of `multi` means there *may* be more than one *declaration* using
the same declared routine name (`kv` in this case). There usually *will*
be more than one. (Otherwise, why was it declared `multi`?)
The normal
> multi method kv ...
Use of `multi` means there *may* be more than one *declaration* using the
same declared routine name (`kv` in this case). There usually *will* be
more than one. (Otherwise, why was it declared `multi`?)
The normal way to *use* a routine is to call it.
If you declare
Tobias thanks!
I ran panda install HTTP::Easy
and it installed the new version in
/Users/gabor/rakudo-star-2015.09/install/share/perl6/site/lib/HTTP/Easy.pm6
but Rakudo is still loading the old one from
/Users/gabor/rakudo-star-2015.09/install/share/perl6/lib/HTTP/Easy.pm6
and crashing.
I can
Hi,
method .send was deprecated in favor of .print (for strings) and .write
(with bufs/blobs)
Maybe Bailador or one of its dependencies needs updating.
Cheers,
Moritz
You need to upgrade HTTP::Easy, it already contains a fix.
Am 26.09.2015 um 12:26 schrieb Gabor Szabo:
> And just to clarify launching this simple script (and then accessing
> it via a browser) would show the same problem:
>
> use lib 'lib';
>
> use Bailador;
>
> get '/' => sub {
> "hello
Am 04.01.2011 03:05, schrieb Nathaniel:
OK: I get this message when running a .pir file from an embedded
parrot interpreter, but not when I actually call parrot from a command
line. My guess is that there is perhaps a .pbc file missing from the
area where I have set up a runtime directory
Awesome Patrick, you totally nailed it ;-)
I'll be submitting a patch soon. Do you know if there is a Parrot bug
logged for the problem you described?
On Mon, Sep 22, 2008 at 12:27 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote:
On Sat, Sep 20, 2008 at 12:46:53PM +0800, Chris Davaz wrote:
In
On Mon, Sep 22, 2008 at 02:35:20PM +0800, Chris Davaz wrote:
Awesome Patrick, you totally nailed it ;-)
I'll be submitting a patch soon. Do you know if there is a Parrot bug
logged for the problem you described?
I don't think there's a Parrot bug filed for the issue of MMD
dispatch on
On Saturday 20 September 2008 22:24:52 Chris Davaz wrote:
If it is the case that :method and :multi are incompatible, I am a bit
surprised to see that in the Rakudo src directory:
I said they're incompatible -- meant in terms of their semantics. I didn't
say they don't work together in some
chromatic wrote:
On Saturday 20 September 2008 22:24:52 Chris Davaz wrote:
If it is the case that :method and :multi are incompatible, I am a bit
surprised to see that in the Rakudo src directory:
I said they're incompatible -- meant in terms of their semantics. I didn't say
they
On Sat, Sep 20, 2008 at 11:05:34PM -0700, chromatic wrote:
On Saturday 20 September 2008 22:24:52 Chris Davaz wrote:
If it is the case that :method and :multi are incompatible, I am a bit
surprised to see that in the Rakudo src directory:
I said they're incompatible -- meant in terms of
Patrick,
Any thoughts on why I am getting the No applicable methods error as
described in the head of this thread?
On Sun, Sep 21, 2008 at 11:38 PM, Patrick R. Michaud [EMAIL PROTECTED] wrote:
On Sat, Sep 20, 2008 at 11:05:34PM -0700, chromatic wrote:
On Saturday 20 September 2008 22:24:52
On Sunday 21 September 2008 03:53:31 Jonathan Worthington wrote:
I said they're incompatible -- meant in terms of their semantics. I
didn't say they don't work together in some cases with our current
implementation. (They probably shouldn't.)
They probably should. If they didn't, then
On Sat, Sep 20, 2008 at 12:46:53PM +0800, Chris Davaz wrote:
In any-str.pir we need to figure out how to change
.sub 'split' :method :multi('String')
into
.sub 'split' :method :multi(_, 'String')
[...]
... let's back up a bit and look at what is really happening.
[...] Any when we change
How does Parrot tell which parameters are the invocants? PDD27 mentions
that parameters can be decorated with :invocant, but that doesn't seem to be
used anywhere.
I'll also note that if :multi and :method don't go together then some of the
language in PDD27 needs to change. For instance, The
On Friday 19 September 2008 21:46:53 Chris Davaz wrote:
In any-str.pir we need to figure out how to change
.sub 'split' :method :multi('String')
into
.sub 'split' :method :multi(_, 'String')
since the former method signature is causing problems for me as I'm
trying to implement
.sub
HaloO,
John M. Dlugosz wrote:
Perl 6 has a concept of a candidate list. The candidate list are
those that could handle the call, typically inherited methods and
multi variations.
Candidate set would be a better term. It is a subset of all long names
of a multi in a lexical scope.
It seems
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Candidate set would be a better term. It is a subset of all long names
of a multi in a lexical scope.
List, not set, because it is ordered. nextsame/nextwith/etc. are
described as invoking the next candidate on the list. Therefore, there
is
On Sat, Apr 19, 2008 at 08:00:07AM -, John M. Dlugosz wrote:
: Perl 6 has a concept of a candidate list. The candidate list are those
that could handle the call, typically inherited methods and multi variations.
:
: It seems that multi variations, at least with respect to the semicolon
HaloO,
John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Candidate set would be a better term. It is a subset of all long names
of a multi in a lexical scope.
List, not set, because it is ordered. nextsame/nextwith/etc. are
described as invoking the next candidate on
I'd have to agree.
I also think that .foo should always mean $_.foo in methods, without causing
any errors if $?SELF =:= $_ becomes false.
OK. There is a lot of historical threads on the subject and already a lot of
legacy in the Perl6 language.
OK - As I understand it, this is what A12
On Thu, July 14, 2005 10:47 am, Autrijus Tang said:
If this were a straw poll, I'd say...
1. Meaning of $_
.method should mean $_.method always. Making it into a runtime
error is extremely awkward; a compile-time error with detailed
explanataion is acceptable but suboptimal.
On 7/14/05, Larry Wall [EMAIL PROTECTED] wrote:
Certainly. The problem is that there are too many viable alternatives,
and half of everyone hates half of the alternatives.
You will know I'm no longer a benevolent dictator when I start to enjoy
watching people squirm every time I change my
On 7/14/05, Juerd [EMAIL PROTECTED] wrote:
It's just a Solomon judgement situation. That can work out well, but I
really hate when it's forced and used to test patience.
If Juerd is right about this being a solomonian situation, let me just
give up my baby to the other woman by saying:
* It's
If this were a straw poll, I'd say...
1. Meaning of $_
.method should mean $_.method always. Making it into a runtime
error is extremely awkward; a compile-time error with detailed
explanataion is acceptable but suboptimal.
2. Topicalization of $?SELF
Neutral on this -- I can
On Thu, Jul 14, 2005 at 05:37:38PM +0200, Carl Mäsak wrote:
On 7/14/05, Juerd [EMAIL PROTECTED] wrote:
It's just a Solomon judgement situation. That can work out well, but I
really hate when it's forced and used to test patience.
If Juerd is right about this being a solomonian situation,
Nathan Gray skribis 2005-07-14 12:55 (-0400):
Autrijus joked? about $?.method once (instead of ./method), in case we
need any more bad alternatives for $?SELF.method. But I also trust
@larry, or %larry, or even $larry, to make a decent choice that will
serve the community well.
Would this
On Wed, Jul 13, 2005 at 07:27:52PM -0400, Stevan Little wrote:
: The way I am viewing the notion of current class for submethods
: currently is:
:
: From inside another method or submethod:
:
: - a submethod should only be called from the class which defines it.
This doesn't sound right to me.
Larry,
Thanks for the detailed reply. Just a few more questions and I think I
can get this into the metamodel :)
On Jul 14, 2005, at 3:40 PM, Larry Wall wrote:
On Wed, Jul 13, 2005 at 07:27:52PM -0400, Stevan Little wrote:
: The way I am viewing the notion of current class for submethods
:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
it'll always be construed as unambigous. You could go so far as to
On Thu, Jul 14, 2005 at 04:31:07PM -0400, Stevan Little wrote:
: A submethod is simply a method that says These
: aren't the droids you're looking for if you call it via either SMD
: or MMD dispatch and the first invocant isn't of the exact run-time
: type of the lexical class. In other words,
Larry,
Thanks much, this all makes sense. :)
Thanks,
Stevan
On Jul 14, 2005, at 4:54 PM, Larry Wall wrote:
On Thu, Jul 14, 2005 at 04:31:07PM -0400, Stevan Little wrote:
: Now, the metamodel currently does not have MMD, and I think next
: METHOD is not as relevant in SMD. So would it make
On Thu, Jul 14, 2005 at 01:39:44PM -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
If .method always
On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
ICK!
Larry Wall skribis 2005-07-14 13:39 (-0700):
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous.
Thus it never means $?SELF.foo without $_ being
Yuval Kogman skribis 2005-07-15 1:09 (+0300):
use dot;
If we have pragmas for the 99 Perl6's that every wacko wants to
have, we won't have any readability.
The syntax needs to be consistent and useful, even at the price of
some danger.
Agreed.
I don't want to be using a language
On Fri, Jul 15, 2005 at 01:09:57AM +0300, Yuval Kogman wrote:
On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the
On Thu, Jul 14, 2005 at 09:38:45PM +0200, Juerd wrote:
Nathan Gray skribis 2005-07-14 12:55 (-0400):
Autrijus joked? about $?.method once (instead of ./method), in case we
need any more bad alternatives for $?SELF.method. But I also trust
@larry, or %larry, or even $larry, to make a decent
On Wed, Jul 13, 2005 at 12:51:49PM -0400, Stevan Little wrote:
: Hello,
:
: More questions for the metamodel. I am trying to add proper submethod
: and private method handling and I have a question about method
: resolution order as a whole. I asked a similar question last week, but
: this
On Tue, Jul 12, 2005 at 04:43:06PM +0530, Aankhen wrote:
: I agree with what is being said here. `.method` is a great way to
: eliminate a lot of repetitive, tedious typing. Surely there is a
: viable alternative that doesn't involve outlawing it?
Certainly. The problem is that there are too
Larry,
On Jul 13, 2005, at 2:30 PM, Larry Wall wrote:
: The Syn/Apoc seem to indicate that methods and submethods of the same
: name can coexist. So the class definition itself is legal. However,
it
: brings up an issue when it comes time to call bar().
If the Syn/Apoc is giving that
Larry Wall skribis 2005-07-11 18:29 (-0700):
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
What?
That makes having a default at
I feel a me too post is in order.
I've written code that is 2-3 levels of nested given/when in a
method of an object that wasn't the topic.
I did not feel confused at all, juggling .foo and ./foo, which are
visually distinct, and different to type. They convey a big
difference of meaning, even
On 7/12/05, Juerd [EMAIL PROTECTED] wrote:
[snip]
Disallowing .method here means a huge step back in time. Back to
$_.method or $object.method.
[snip]
I agree with what is being said here. `.method` is a great way to
eliminate a lot of repetitive, tedious typing. Surely there is a
viable
Autrijus Tang wrote:
The compiler, in turn inspect whether there's an bound $_ in scope
with $?SELF set. It is not trivial, because this should work:
sub baz (c) { c() }
method foo { baz { .bar } } # $_ is free in inner closure
But this needs to fail:
sub baz (c) { c(1) }
On Tue, Jul 12, 2005 at 12:36:23PM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 09:04:54PM -0700, Larry Wall wrote:
: On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: : On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: : The obvious thought is to have yet
On Sat, 9 Jul 2005, Robin Redeker wrote:
I wasn't thinking 'cool', I was thinking 'visually distinctive and
mnemonic'. I actually think o. is cooler.
Yes, i would like o. more too. At least it doesn't introduce
a completly meaningless '/' preceded by a '.'.
Hmmm... I am one of those who
On Mon, Jul 11, 2005 at 11:14:18AM +0200, Michele Dondi wrote:
: Hmmm... I am one of those who likes ./ more, instead. I mean, I _really_
: like it! Thus, how about making '/' less meaningless, i.e. more
: meaningful, in more general situations?!?
Um, do you have a specific proposal? Like
Larry~
On 7/11/05, Larry Wall [EMAIL PROTECTED] wrote:
On Mon, Jul 11, 2005 at 11:14:18AM +0200, Michele Dondi wrote:
: Hmmm... I am one of those who likes ./ more, instead. I mean, I _really_
: like it! Thus, how about making '/' less meaningless, i.e. more
: meaningful, in more general
On Mon, Jul 11, 2005 at 04:50:56PM -0400, Matt Fowles wrote:
: Yay! I guess I will take this moment to resuggest @^ as a list of
: invocants and $^ =:= @^[0]. I like how the ^ kinda points you the
: right way, also visually distinctive and doesn't get in the way of
: $_...
I don't see much use
(Cross-posting the new ruling from p6l to p6c to discuss implementation
strategy)
On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
{
let $Larry.decisive = 1;
Okay, this is what we're gonna do. We're gonna go back pretty close to
where we were originally, but with a
On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: The obvious thought is to have yet another magical, $^H like flag, to
: denote the current dialect. If it is set, then the parser can emit
: .method as $_.method, instead
On Mon, Jul 11, 2005 at 09:04:54PM -0700, Larry Wall wrote:
On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: The obvious thought is to have yet another magical, $^H like flag, to
: denote the current dialect. If it
On Sat, Jul 09, 2005 at 07:36:10AM -0700, Larry Wall wrote:
: Why does it have to be some sugared syntax when you can just simple
: name it in the parameter list?
:
: Yes, but there seem to be quite some people who want
: a 'cool' syntax for it. (ie. ./method ()).
I wasn't thinking
On 7/9/05, Robin Redeker [EMAIL PROTECTED] wrote:
On Sat, Jul 09, 2005 at 07:36:10AM -0700, Larry Wall wrote:
: Why does it have to be some sugared syntax when you can just simple
: name it in the parameter list?
:
: Yes, but there seem to be quite some people who want
: a 'cool'
On Fri, Jul 08, 2005 at 08:50:35AM -0500, Jonathan Scott Duff wrote:
On Fri, Jul 08, 2005 at 08:10:00AM +0200, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
On Fri, Jul 08, 2005 at 08:50:35AM -0500, Jonathan Scott Duff wrote:
On Fri, Jul 08, 2005 at 08:10:00AM +0200, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
On Fri, Jul 08, 2005 at 10:07:24AM -0400, Stevan Little wrote:
On Jul 8, 2005, at 2:10 AM, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
syntax, which completly
On Fri, Jul 08, 2005 at 08:28:34PM +0200, Robin Redeker wrote:
: On Fri, Jul 08, 2005 at 10:07:24AM -0400, Stevan Little wrote:
: I have never understood what is wrong with this:
:
: method foo ($self: $bar) {
: $self.baz()
: }
:
: Thats a fine option to have.
: But therecomes another
On Fri, Jul 08, 2005 at 05:43:01PM +0200, Robin Redeker wrote:
: Maybe per .-file in the home-directory, like .vimrc ...
Only if pulled in with a use. I don't want to see Perl programs
implicitly starting in a variant language. Dialects must be declared.
Otherwise you're in a situation like
On Thu, Jul 07, 2005 at 08:12:17PM -0700, Larry Wall wrote:
The basic problem is that I always hated looking at C++ and not knowing
whether I was looking at a function or a method, so I'm not going to
make standard Perl work like that. On the other hand, there's always
use self ;
to
On Fri, Jul 08, 2005 at 08:10:00AM +0200, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
syntax, which completly wont fit into the language,
What a way to win
On Jul 8, 2005, at 2:10 AM, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
syntax, which completly wont fit into the language, whose
favorite will be the default?
On Thu, Jul 07, 2005 at 10:32:37PM +0200, Robin Redeker wrote:
Hi,
i just wanted to ask what was about the method calling syntax on
$self, and why does
method ()
not work for calling a method on $self? (like in C++)
Because perl can't distinguish between the method foo() and the
On Thu, Jul 07, 2005 at 04:08:17PM -0500, Jonathan Scott Duff wrote:
On Thu, Jul 07, 2005 at 10:32:37PM +0200, Robin Redeker wrote:
Hi,
i just wanted to ask what was about the method calling syntax on
$self, and why does
method ()
not work for calling a method on $self?
On 7/8/05, Robin Redeker [EMAIL PROTECTED] wrote:
Hi,
i just wanted to ask what was about the method calling syntax on
$self, and why does
method ()
not work for calling a method on $self? (like in C++)
IIRC, Larry wants to be able to distinguish method calls from sub
calls, so that
The basic problem is that I always hated looking at C++ and not knowing
whether I was looking at a function or a method, so I'm not going to
make standard Perl work like that. On the other hand, there's always
use self ;
to go with everyone else's preferences:
use self .
use self `
LW == Larry Wall [EMAIL PROTECTED] writes:
LW to go with everyone else's preferences:
LW use self .
LW use self `
LW use self ·
LW use self ..
LW use self ^.
LW use self i.
LW use self o.
LW use self ¤.
LW use self me.
LW use self
On Mon, Jun 20, 2005 at 07:34:57PM -0400, Kurt wrote:
On 6/18/05, Juerd wrote:
Why exactly is the slash not acceptable for you? Almost everyone has
said they like it. I personally find ./method prettier and easier to
type than any of the alternatives.
I don't like it because I think
Juerd wrote:
Kurt skribis 2005-06-20 19:46 (-0400):
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Certainly.
However, there has proven to be much demand for something like
What does this have to do with perl6-internals? F-up to p6l.
Matthew Zimmerman skribis 2005-06-21 11:27 (-0400):
$self-_fraction * $self-concentration +
$s2-_fraction * $s2-concentration
You can still write it like that, if you declare a
Jonathan Scott Duff skribis 2005-06-21 10:00 (-0500):
I expect that soon after perl6 is released (heck, maybe before it's
released) we'll get tools that will translate perl6 to perl6 while
performing some syntactic manipulation. For instance, it could
explicitize code (replacing ./method with
Juerd wrote:
What does this have to do with perl6-internals? F-up to p6l.
Sorry! Typing faster than my brain is working. Resent to the right list.
If I have a complicated mathematical expression
If you have anything that is complicated, a verbose version should
always be considered, if
[Sorry, sent this to the wrong list by mistake.]
Matthew Zimmerman wrote:
Juerd wrote:
Kurt skribis 2005-06-20 19:46 (-0400):
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
On 6/21/05, Matthew Zimmerman [EMAIL PROTECTED] wrote:
Could we revisit the idea of using a shorter keyword for $?SELF, like
'o'? I know that $Larry said the idea was probably not going to work:
http://tinyurl.com/7baz6
but I'm curious if the reasoning that killed it then still holds
On 6/18/05, Juerd wrote:
Why exactly is the slash not acceptable for you? Almost everyone has
said they like it. I personally find ./method prettier and easier to
type than any of the alternatives.
I don't like it because I think method calls should look like method calls,
and the slash
Kurt skribis 2005-06-20 19:34 (-0400):
However, if it remains official, I expect I'll simply be naming my
invocants, as chromatic has suggested.
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
Juerd
--
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Kurt
Kurt skribis 2005-06-20 19:46 (-0400):
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Certainly.
However, there has proven to be much demand for something like ./method,
and in such
John Siracusa wrote:
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 :)
Heh, it is indeed. And it means given the 16,000,000 lines of Perl in
CPAN, we only have to keep
On Jun 18, 2005, at 9:24 PM, Damian Conway wrote:
chromatic wrote:
I find it ugly enough that I plan to name my invocants explicitly.
...which should be construed as a *feature* of the current syntax. ;-)
Damian
In that case, why do we have this feature?
Seriously. Are default
David Storrs skribis 2005-06-19 13:45 (-0400):
Seriously. Are default invocants really such a good idea?
Yes, as long as the default is $_.
./method doesn't use a default invocant. It calls method on the current
invocant, which happens to be available as $?SELF: that doesn't mean it
defaults
The reason we ended up at ./method was simply because it was the best
suggestion anyone had.
Compared to the previous suggestions it was way ahead.
It's other advantage is that (except for on nordic keyboards) dot and
slash are generally right next to each other, so the expense of using it
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
At 7:52 AM -0400 6/18/05, John Siracusa wrote:
That actually looks more private to me. Let's line 'em up again:
PUBLIC PRIVATE
-- --
./method() .:method()
[EMAIL PROTECTED]() .:method()
.method() .:method()
.:method() .method()
.:method()
Darren Duncan skribis 2005-06-18 11:40 (-0700):
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 like
part of an operator but it isn't).
Except for
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
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 not acceptable for you? Almost everyone has
said
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
John Siracusa skribis 2005-06-18 20:16 (-0400):
On 6/18/05 7:54 PM, Juerd wrote:
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
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 not
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
John Siracusa skribis 2005-06-18 20:35 (-0400):
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 :)
Do you really think so? I think that there is no way that Perl 5 can
John Siracusa skribis 2005-06-18 20:33 (-0400):
I literally didn't even consider that it could be some sort of new
syntax--and that's saying a lot considering I was reading p6l.
You missed a 33 message thread that was referred to many times. Such
things happen, I am surprised by new inventions
On Sun, 2005-06-19 at 02:11 +0200, Juerd wrote:
Why exactly is the slash not acceptable for you? Almost everyone has
said they like it.
I find it ugly enough that I plan to name my invocants explicitly.
-- c
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
chromatic wrote:
I find it ugly enough that I plan to name my invocants explicitly.
...which should be construed as a *feature* of the current syntax. ;-)
Damian
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 Jun 17, 2005, at 10:42 PM, John Siracusa wrote:
But the truth is that /
really does look file-path-y to me, and just plain old ugly. I
think at
least two other people had similar reactions (Martin Kuehl and Carl
Franks).
David Storrs, reporting to show solidarity, sir(acusa)!
Maybe
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?
1 - 100 of 212 matches
Mail list logo
