I have done a quick scan of the archives for a
discussion on this topic and didn't see it; if I
just missed it, I'd appreciate it if someone
could send me a link to the thread or
applicable RFC[s].
I suspect you didn't use the all search, right?
Just in case:
http://www.mail
analysis support from the compiler.
So, no more on that here from me...
Larry's MMV on that ;-)
Man I really need to get up to speed with these
acronyms. I know YMMV, is MMV a distant
cousin perhaps?
[strict typing]
Not a negative, but realize that many people find it
of less value than the annoyances it brings with it
(myself included)
Michael, I don't know which is more impressive; the
fact that use of a strictly typed language implies that
a copy of you would land on the poor
Afaict, even with use strict at its most strict, perl 6
can't (in practice) complain, at compile time, if
$foo.Foun
refers to an undeclared Foun.
it is already detectable. from perldoc perlref:
Perhaps for perl 5, but, aiui, Damian confirmed
that my thinking about
that warns if a
method name matches a built in property name?
--
Q1 followed from me thinking about my/our concepts
as they might apply to properties. The more I thought
about it, the more I gravitated toward the proposed
system (lowercase for builtins, Mixedcase for user
defined, only
with the newer Perl,
conflicting names would immediately break or warn,
which it seems to me would be a Good Thing.
On Tue, Jun 05, 2001 at 04:38:24PM -0500, Me wrote:
Question 1:
Afaict, even with use strict at its most strict, perl 6
can't (in practice) complain, at compile time, if
$foo.Foun
refers to an undeclared Foun.
Right?
Can't you hear the low roar from
Consider the code:
my $foo = 1 is Found;
bar($foo);
sub bar { my $baz = shift; if ($baz.Found) { ...} }
Does the value of $baz have the Found property?
Yes.
If so, does the compiler know that?
No. Because it only has the property
Afaict, even with use strict at its most strict, perl 6
can't (in practice) complain, at compile time, if
$foo.Foun
refers to an undeclared Foun.
Right?
Should there be a strict mode that warns if a
method name matches a built in property name?
Just a thought. No need for replies.
Suggestion: rename local your.
my is mine, nothing to do with anyone else's code.
our is ours, used in my code and declared in a package
known to my code.
your is yours, the value used in code I call. Oh, and
it's also ours.
an ordered hash is common
Arrays too.
not wise ... to alter features just for beginners.
Agreed.
(PS 11 people isn't a statistic, its a night at the pub)
Your round...
The extra complexity of a separate hash syntax might
be justified for other reasons, but not the ones
Hm, OK. What does this access and using what method ?
$foo = '1.2';
@bar[$foo];
This is an argument against conflating @ and %.
It has nothing to do with using [] instead of {}.
(I accept that the @/% issue is problematic. Otoh,
I don't yet see @/% conflation as being obviously
a bad
[] and {}.
---
Please bear with me just a (hoefully little) longer.
Ok, why not deprecate %foo and always use @
instead and have [] and {} represent two indexing
name spaces?
In perl 6 experiments, and perl 7, you'll have % to
play with.
As someone else pointed out (I forget who). But beginners are not
always the best people to ask. Beginner don't stay beginners for
long I think the quote was.
And as I said before, I agree.
I picked the beginners list as much because it was
active as anything else. They are *somebody* after
(i.e. ordered or associative).
A (probably futile, but one has to try) plea for
people to use numbered rather than ordered.
@foo = ['England', 'France', 'Germany'];# unordered
%foo = {First = Fred', Last = 'Bloggs']; # ordered
(I'd also suggest named instead of the scientific
I will read replies, and respond to off list emails,
but I will refrain from posting to the list on this topic
for at least one week.
If you have nothing new to add, then please don't post.
Suggestion: pseudohash.
%foo{Fred} = 'Bloggs';
$bar = %bar[1];# $bar is 'Bloggs'
My apologies if the following has already been suggested.
I know Larry said the colon was his, but presumably he's
not talking about the double colon, as currently used as a
package name separator, right?
What if:
use Foo::Bar qw/ qux waldo /;
can be written:
use Foo::Bar :: qux
Larry:
Currently, @ and [] are a promise that you don't intend to use string
indexing on this variable. The optimizer can make good use of this
information. For non-tied arrays of compact intrinsic types, this
is going to be a major performance win in Perl 6.
Assuming that optimization
: Assuming that optimization opportunities remained intact,
They won't, but go on.
Because the syntax won't provide the compiler enough info?
: do you think conflating @ and % would be a perl6 design win?
Nope, I still think most ordinary people want different
operators for strings
So bool would perhaps be a synthetic property that has opposite
polarity
from bit? I can see that, sort of. It's something like electrons
being
negative, thank you Mr. Franklin.
s/bit/yes/
yes?
And, despite perl5's use of no as the opposite
of use, and given that there may be no use in
If you're trying to confuse me, I can assure you it's unnecessary.
;-)
Hey, I try.
--me
(Under cover Ruby/Python agent and
promotor of RFCs 380 thru 1,000,000)
Well clearly on is the opposite of no. Yes?
maybe, as in:
my cat maybe Dog;
for some form of relaxed typing constraint.
crazy cackle
101 - 122 of 122 matches
Mail list logo
