David Green wrote:
> I bet we actually don't disagree much; I'm not really against "ro" --
> I'm just not against "readonly" because of its length. If I were
> writing casually, I'd use "rw" and "ro"; formally, I'd use "read only"
> and "read/write" (or even "readable and writable"). At an in-bet
On 2008 Sep 24, at 17:45, David Green wrote:
On 2008-Sep-23, at 5:27 pm, Michael G Schwern wrote:
David Green wrote:
Happily, brevity often aids clarity. The rest of the time, it
should be up to one's editor; any editor worth its salt ought to
easily auto-complete "ro" into "readonly".
Ee
On 2008-Sep-23, at 5:27 pm, Michael G Schwern wrote:
David Green wrote:
Happily, brevity often aids clarity. The rest of the time, it
should be up to one's editor; any editor worth its salt ought to
easily auto-complete "ro" into "readonly".
Eeep! The "your IDE should write your verbose c
Michael G Schwern schwern-at-pobox.com |Perl 6| wrote:
John M. Dlugosz wrote:
I'm not opposed to having it be "ro", but wonder why he didn't call it that
in the first place, so there must be a reason.
Nobody's perfect?
My other thought is that since parameters are read-only by default
Michael G Schwern schwern-at-pobox.com |Perl 6| wrote:
It should be possible to alias it in your own scope easily.
Every time someone replies to a Perl 6 language design nit with "but you can
change the grammar" *I* kill a kitten.
*meowmmmf*
That would not be a change in the gramma
David Green wrote:
> On 2008-Sep-23, at 2:32 pm, Michael G Schwern wrote:
>> My other thought is that since parameters are read-only by default
>> it's not
>> thought you'd have to write it much so clarity wins out over brevity,
>> the flip
>> side of Huffamn encoding. But that doesn't work out so
On 2008-Sep-23, at 2:32 pm, Michael G Schwern wrote:
My other thought is that since parameters are read-only by default
it's not
thought you'd have to write it much so clarity wins out over
brevity, the flip
side of Huffamn encoding. But that doesn't work out so good for
normal
variable de
John M. Dlugosz wrote:
> I'm not opposed to having it be "ro", but wonder why he didn't call it that
> in the first place, so there must be a reason.
Nobody's perfect?
My other thought is that since parameters are read-only by default it's not
thought you'd have to write it much so clarity wins o
PS Incidentally, it seems silly to have "is rw" but not "is ro". I keep
writing "is ro".
The synopses says "readonly". But now that it is possible, I nominate changing
a hyphen.
I'm not opposed to having it be "ro", but wonder why he didn't call it that in
the first place, so there mu
Patrick R. Michaud wrote:
> On Sun, Sep 21, 2008 at 07:02:37PM -0700, Michael G Schwern wrote:
>> I'm pondering what the proper syntax is for a subroutine parameter with both
>> a
>> trait and a default. That is...
>> sub foo ($arg = 42)
>> and
>> sub foo ($arg is readonly)
>> together
HaloO,
Patrick R. Michaud wrote:
The STD.pm grammar [1] shows that the second is the correct form --
i.e., default values occur after traits.
IIRC, there used to be an 'is default(42)' trait that could
be placed arbitrarily.
PS Incidentally, it seems silly to have "is rw" but not "is ro".
On Sun, Sep 21, 2008 at 07:02:37PM -0700, Michael G Schwern wrote:
> I'm pondering what the proper syntax is for a subroutine parameter with both a
> trait and a default. That is...
> sub foo ($arg = 42)
> and
> sub foo ($arg is readonly)
> together in one parameter. Would that be
>
I'm pondering what the proper syntax is for a subroutine parameter with both a
trait and a default. That is...
sub foo ($arg = 42)
and
sub foo ($arg is readonly)
together in one parameter. Would that be
sub foo ($arg = 42 is readonly)
or
sub foo ($arg is rea
13 matches
Mail list logo
