>> print "date" if $var.isa(int);
>> print "date" if isa $var: int;
>> print "date" if $var ~~ int;
>>
>> Those should all work. IMO the first reads the best. That will also
>> work for Cs, as C is a subclass of C (I think).
>
> These only determine if $var is of type int or Int. How
> (1)
>
> my size(4), human DNA ($alpha, $beta, $gamma, $delta ) = ( 'atgc',
> 'ctga', 'aatt', 'ccaa' );
>
> is so perfect, vs
>
> (2)
>
> my DNA ($alpha, $beta, $gamma, $delta) is human, size(4) = ( 'atgc',
> 'ctga', 'aatt', 'ccaa' );
If I were concerned about this, I would either do it the way
Now, I might be stupid, but I keep asking myself what you would need a
property for in this example. To me, it totally confuses the
underlying structure. When was the last time you asked an integer to
identify itself as a valid credit card number?
It is _not_ a property of the integer that it is
Murat Ünalan wrote:
And that shows precisely why Perl 6 does it the other way.
Prepending extended properties like that makes the
declaration almost unreadable. Because it separates the
I shoot in my own foot. My example was extremly bad. Give me a better
try:
(1)
my size(4), human DNA ($
On Sun, 5 Jan 2003, Murat Ünalan wrote:
> > Properties *can* be smart-matched:
> >
> > print "creditcard" if $var.prop().{CreditCard} ~~ 'VISA';
> > or:
> > print "creditcard" if $var.prop{CreditCard} ~~ 'VISA';
> > or:
> > print "creditcard" if $var.CreditCard ~~ 'VISA';
> >
> I think
> And that shows precisely why Perl 6 does it the other way.
> Prepending extended properties like that makes the
> declaration almost unreadable. Because it separates the
I shoot in my own foot. My example was extremly bad. Give me a better
try:
(1)
my size(4), human DNA ($alpha, $beta, $ga
> Why should you care? Perl 6 isn't going to be that strictly
> typed, is it?
Not even optional ?
Murat
Murat Ünalan wrote:
Then you're just not thinking in enough simultaneous dimensions:
my int ($pre, $in, $post) is constant
= (0,1, 2);
This could been written faster in a single line, without decorating with
extra newline+tab+tab+tab+tab:
It's source code. Four extra
> Properties *can* be smart-matched:
>
> print "creditcard" if $var.prop().{CreditCard} ~~ 'VISA';
> or:
> print "creditcard" if $var.prop{CreditCard} ~~ 'VISA';
> or:
> print "creditcard" if $var.CreditCard ~~ 'VISA';
>
> Damian
>
I think this is similar to "John Williams" su
> Yes, but
>
> my int $foo is constant;
>
> Is self-explanatory for many language-speakers. If I recall,
> the set of cross-language-programmers is a proper subset of
> the set of language-speakers. It is clear which is clearer :).
You do "proof by best case scenario". In my previous posti
> > where the distance grows with property-syntax-complexity.
>
> Oh, *that's* what you're concerned about?
> Then you're just not thinking in enough simultaneous dimensions:
>
>
> my int ($pre, $in, $post) is constant
> = (0,1, 2);
This could been written faster i
Murat Ünalan wrote:
print "creditcard" if $var ~~ CreditCard( 'VISA' );
Brought to a point: Properties could be also smart matched.
Properties *can* be smart-matched:
print "creditcard" if $var.prop().{CreditCard} ~~ 'VISA';
or:
print "creditcard" if $var.prop{CreditCard} ~~ 'VISA';
or:
pr
On Sat, 4 Jan 2003, Murat Ünalan wrote:
>
> print "creditcard" if $var == CreditCard( 'VISA' );
>
> wich should do a mod10 on $var and then match a regex or something.
>
> I think one could say "CreditCard( 'VISA' )" is then the property. And
> after
> reading further seeing it could be smart matc
Murat Ünalan wrote:
Oh yes. Psycho-affectivly it is disturbing seeing the group of variables
($pre, $in, $post) teared apart from the initilizing (0..2). This is my
second step in the brain when analysing it. And this is prone to
problems like in:
my int ($one, $two, $three, $four, $five, $six,
Luke Palmer wrote:
> In Perl 5,
>
> my int ($one = 0, $two = 1, $three = 2);
>
> is a fatal error. I could argue for this to change, as to support
> better readability (and it would). It's obvious WIM, so why doesn't
> it DWIM (disclaimer: cannot be used as an argument for arbitrary
> featu
> my $var = 0;
> # or my $var = "0";
> # or my int $var = 0;
> # or my num $var = 0;
>
> # all 4 cases should print "is integer"
> print "is integer" if int $var == $var;
>
> This should work as a more generic method to test Integer
> *value*, rather than type, which IMHO is more useful (and
>
> From: =?iso-8859-1?Q?Murat_=DCnalan?= <[EMAIL PROTECTED]>
> Date: Sat, 4 Jan 2003 14:50:22 +0100
>
> > > my int ($pre, $in, $post) is constant = (0..2);
> > >
> > > Two things "type and property" that belong so together
> >
> > Do they? Surely the type and constancy of a variable are
> > ent
> > In the above case int($var) == $var returns true when I
> would want it
> > to return false.
>
> print "date" if $var.isa(int);
> print "date" if isa $var: int;
> print "date" if $var ~~ int;
>
> Those should all work. IMO the first reads the best. That
> will also work for C
> > It's also far slower. Constructing a 31-element list, junctionizing
> > it,
>
> This might well be done at compile-time. And/or, lazily. So
> the cost of these two steps is likely to be negligible.
>
> > then testing against each element vs. 2 numeric comparisons.
>
> Yes. That's a signifi
> > my int ($pre, $in, $post) is constant = (0..2);
> >
> > Two things "type and property" that belong so together
>
> Do they? Surely the type and constancy of a variable are
> entirely orthogonal to each other.
Oh yes. Psycho-affectivly it is disturbing seeing the group of variables
($pre, $
[EMAIL PROTECTED] (Joe Gottman) writes:
> In the above case int($var) == $var returns true when I would want it to
> return false.
Why should you care? Perl 6 isn't going to be that strictly typed, is it?
--
I wish my keyboard had a SMITE key
-- J-P Stacey
Damian Conway wrote:
Piers Cawley wrote:
Acknowledgements
But, of course, modesty forebade him from thanking the tireless Perl 6
summarizer himself, for his sterling efforts wading through the morasses
that are P6-language and P6-internals
Remembering e.g. perl6 operator threads, brrr, I
Luke Palmer wrote:
>>> From: "Joe Gottman" <[EMAIL PROTECTED]>
>>> Date: Fri, 3 Jan 2003 22:25:16 -0500
>>>
>>> "JG" == Joe Gottman <[EMAIL PROTECTED]> writes:
>>>
>>> JG> Speaking of which, is there a run-time test to check if a variable
>>> JG> is of
>>> JG> integral type? Somethin
23 matches
Mail list logo