Re: AW: "my int( 1..31 ) $var" ?
Christian Renz wrote: Now, I might be stupid, but I keep asking myself what you would need a property for in this example. Yes. It's important to remember that the shiny new hammer of properties is not necessarily the appropriate tool to beat on *every* problem. :-) Damian
Re: 'my int( 1..31 ) $var' ?
>> If I have "0", it's possible I might at some point (this having been >> user input perhaps) have some reason to care whether it was an integer >> or a string. > > How would the user distinguish when providing the input? The Perl 5 having slept now, the same thought occurs to me ... I think I wasthinking of the user typing "0" to show that they're putting it in in string context ... but then the variable would hold ""0"" ... which seems like it'd solve the problem itself, at that point, since a user defined entity can now /\"\d+\"/ to find out if it's built that way even if it does collapse back to a number >> I know I hate the fact that, in almost every lang I use, adding the >> strings "014" and "231" requires me to do ' "" + string1 + "" + >> string2 ' > > Fortunately Perl isn't one of those languages. In general you need for I should learn not to read/respond when i'm tired :o I was thinking of all the Java & JS I've been doing the last couple weeks. Perl I'd just do "$a$b" and be done with it. >> ... I imagine there might exist cases where the information is useful >> ... > > I'm struggling to think of any -- if you come up with some please could > you mail them so I can understand your viewpoint better. Needing to > know about this kind of thing strikes me as most unPerlish. Yeah, since the user would have to in some way dicatate that it was a string value (typing "0" or such), the code will actually receive enough information to build that if the programmer wants it. And I have ZERO idea what I was thinking of as a "useful case" ... But since it is user-garnerable information, and no cases are springing to mind, I retract my earlier comments and say that it might be interesting in some case, but in the same case it is feasible to simply allow the programmer to generate it rather than killing ops generating it automatically ... --attriel (I'll quit posting just before I go to bed now :o)
Re: 'my int( 1..31 ) $var' ?
Attriel wrote: > Well, in general I think it would be good to have some mechanism for > determining the type of the data rather than the type of a > representation of the contained value. Why? One of the nice things about Perl is that coercian takes care of these kind of things so that you don't have to worry about them. If you pass a string containing a sequence of digit characters when an integer is expected, Perl just works it out. > If I have "0", it's possible I might at some point (this having been > user input perhaps) have some reason to care whether it was an integer > or a string. How would the user distinguish when providing the input? The Perl 5 ways of reading input -- whether from the keyboard, a file, or a form on a webpage -- yield strings. Even if the user thinks she has provided an integer, the program gets a string (but that doesn't matter). For validation purposes things like Regexp::Common are currently handy for determining whether provided input can be treated as a number or an integer or whatever. Perl 6's ability to use its own grammar rules should make those kinds of things considerably easier. > I know I hate the fact that, in almost every lang I use, adding the > strings "014" and "231" requires me to do ' "" + string1 + "" + > string2 ' Fortunately Perl isn't one of those languages. In general you need for either variables or operators to be typed. JavaScript has problems with untyped variables and addition/concatenation; PHP has problems with string/numeric comparisons. Many languages 'solve' this problem by ensuring all variables have types. Perl goes the other way and ensures operators are sufficiently typed, having C<+> and C<.>, and C and C<< < >>. Perl 5 fell down in having the bitwise operators behave differently with numbers and strings; Perl 6 fixes this by having different operators for each operation. So the type that data has previously been (albeit possibly only in the mind of the user who entered it) isn't particularly useful; if the data can be coerced to that type (or any other required type), then that is sufficient. > ... I imagine there might exist cases where the information is useful > ... I'm struggling to think of any -- if you come up with some please could you mail them so I can understand your viewpoint better. Needing to know about this kind of thing strikes me as most unPerlish. Smylers
Re: 'my int( 1..31 ) $var' ?
>> 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. However: > > 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 more commonly wanted). Well, in general I think it would be good to have some mechanism for determining the type of the data rather than the type of a representation of the contained value. If I have "0", it's possible I might at some point (this having been user input perhaps) have some reason to care whether it was an integer or a string. I know I hate the fact that, in almost every lang I use, adding the strings "014" and "231" requires me to do ' "" + string1 + "" + string2 ' since if I 'string1 + string2' I get integer addition and end up with a single number 245, or '"" + string1 + string2' becomes the string "245". I've come to accept it, and I realize that 'var-typed(string1) + var-typed(string2)' takes more characters, looks uglier, and is generally more annoying in all ways for that problem, but I imagine there might exist cases where the information is useful ... I suppose it could be stored at input time as a ... variable property (?) that the program sets, but once it's read, I'm not sure the information exists in any meeans to produce the information FOR the property, so it would have to be set in the input functions themselves ... Admittedly, the value-type is goin to be more interesting in a large majority of the cases, so it probably SHOULD continue being the default low-effort result ... I had a point. I think I made it in there. --attriel
Re: AW: "my int( 1..31 ) $var" ?
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 a valid cc number,
rather it happens that it will be accepted as valid _by a certain
authority_. So why not go and ask the authority? Compare the case to a
phone number -- the phone number itself doesn't know if its valid. You
could only check a certain format (if e.g. in the USA, in Germany,
that would be very hard). To check the validity, query a directory
server or ask a phone to dial the number. Don't check the number
itself.
To provide even stronger evidence against using properties, consider
the fact that a credit card number will only be accepted with an
expiration date and -- with good merchants -- the three or four-digit
security code on the back of the card. Now you're up to doing
something like
# funky syntax ahead
my $cc = [ num => "8765 4321", expdate => "0799", code => "123" ];
# do magic
# ...
print "I'm rich!" if $cc.prop{CreditCard("CAMELCARD")};
Ouch! I may be conservative, but again I think you should go and ask
the authority (ie., a validation service). The authority in this case
probably is already encapsulated in a CPAN module and could look like
this:
use CreditCard::Validation;
deduct(10_000_000) if validate($number, $expdate, "PERLIAN EXPRESS");
or something like
use CreditCard::Validation qw(ISA CAMELCARD MONKSCLUB);
deduct(10_000_000) if validate($number, $expdate, $bankcode);
depending on your tastes. Yep, it doesn't use funky perl 6 syntax, but
it SWIMs (Says What I Mean, ie. it is readable).
Greetings,
Christian
--
[EMAIL PROTECTED] - http://www.web42.com/crenz/ - http://www.web42.com/
"If God were a Kantian, who would not have us till we came to Him from
the purest and best motives, who could be saved?"
-- C.S. Lewis, The Problem of Pain
Re: AW: AW: "my int( 1..31 ) $var" ?
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 this is similar to "John Williams" suggestion:
>
> print "creditcard" if CreditCard( $var ) eq 'VISA';
Well, no. In my suggestion, CreditCard is a sub which checks whether $var
is a valid credit card, returning the card type.
In Damian's example, he is assuming $var already has a property assigned
to it called CreditCard possibly containing the value 'VISA'. So his has
less processing they either of ours.
The problem I see with:
> print "creditcard" if $var ~~ CreditCard( 'VISA' );
is that CreditCard does not know what $var is. Even if you overload the
smartmatch operator on $var's class, it is still comparing $var with the
value returned from CreditCard.
> sub CreditCard
> {
> #connect to a "specific" database (VISA, MASTERCARD, ..)
> #compare with "non-blocked or valid" cards
> }
...
> Excerpt: My concept is to have a twofold view about "properties". One
> thing that is attributing a type during decleration, and something that
> could verified against in other context. All my thinking on that
> orginates from Damians Attribute::Type.
>
> Hopefully i do not confuse you too much.
A sub is not a property. It might be a method, which could sometimes look
like a property (as in Damian's third example), but you have strayed so
far away from properties that you are talking about something else now.
~ John Williams
AW: "my int( 1..31 ) $var" ?
> Why should you care? Perl 6 isn't going to be that strictly > typed, is it? Not even optional ? Murat
AW: AW: "my int( 1..31 ) $var" ?
> 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" suggestion:
print "creditcard" if CreditCard( $var ) eq 'VISA';
It is something different to scan a database of card types and return a
list of possible matches, instead
of just testing one requested card type. What if CreditCard is such a
routine
sub CreditCard
{
#connect to a "specific" database (VISA, MASTERCARD, ..)
#compare with "non-blocked or valid" cards
}
or
sub CreditCard
{
#cycle through all 800 CreditCard types and return matches
}
Then Damians suggetion
> print "creditcard" if $var.CreditCard ~~ 'VISA';
could mean heavy processing, but
print "creditcard" if $var ~~ CreditCard( 'VISA' );
would be short work.
Excerpt: My concept is to have a twofold view about "properties". One
thing that is attributing a type during decleration, and something that
could verified against in other context. All my thinking on that
orginates from Damians Attribute::Type.
Hopefully i do not confuse you too much.
Murat
Re: AW: "my int( 1..31 ) $var" ?
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:
print "creditcard" if $var.CreditCard ~~ 'VISA';
Damian
Re: AW: "my int( 1..31 ) $var" ?
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 matched like: > > print "creditcard" if $var ~~ CreditCard( 'VISA' ); > > Brought to a point: Properties could be also smart matched. Wouldn't it be easier to say: print "creditcard" if CreditCard( $var ) eq 'VISA'; ~ John Williams
AW: "my int( 1..31 ) $var" ?
> 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 > more commonly wanted). > I agree. And i found an interesting thread about that in comp.object http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&oe=UTF-8&threadm=1990S ep28.181057.16740%40odi.com&rnum=5&prev=/groups%3Fq%3DVariable%2BTypes%2 BVs%2BValue%2BTypes%26hl%3Dde%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3 D1990Sep28.181057.16740%2540odi.com%26rnum%3D5 Murat
AW: "my int( 1..31 ) $var" ?
> > 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 Cs, as C is a subclass of C > (I think). > > Luke and that should also work print "date" if $var ~~ PropertyDate( 'monthday' ); smart match against a property. 'isa' wouldn't help then ? Murat
AW: "my int( 1..31 ) $var" ?
> > 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 significant cost in this case. My example was bad. I intended something with more behind it. 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 matched like: print "creditcard" if $var ~~ CreditCard( 'VISA' ); Brought to a point: Properties could be also smart matched. Murat
Re: "my int( 1..31 ) $var" ?
[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
Re: "my int( 1..31 ) $var" ?
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? Something like >>> JG> print "date" if ($var is int) && (1 <= $var <= 31); >>> >>> the old standby is: >>> >>> int( $var ) == $var >> >>I'm not sure if this works. >> >> my $var = "0"; # Notice the quotation marks >> print "is integer" if (int($var) == $var); >> >> In the above case int($var) == $var returns true when I would want it to >> return false. Why? It returns true in perl5; 0 certainly is an integer value. > 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. However: 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 more commonly wanted). This message was sent using the Webmail System hosted by OARDC Computing Services -- http://webmail.oardc.ohio-state.edu:8080
Re: "my int( 1..31 ) $var" ?
> 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 > is of > > JG> integral type? Something like > > > > JG> print "date" if ($var is int) && (1 <= $var <= 31); > > > > the old standby is: > > > > int( $var ) == $var > > > >I'm not sure if this works. > > my $var = "0"; # Notice the quotation marks > print "is integer" if (int($var) == $var); > > 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 Cs, as C is a subclass of C (I think). Luke
Re: "my int( 1..31 ) $var" ?
- Original Message - From: "Uri Guttman" <[EMAIL PROTECTED]> To: "Joe Gottman" <[EMAIL PROTECTED]> Cc: "Perl6" <[EMAIL PROTECTED]> Sent: Friday, January 03, 2003 10:06 PM Subject: Re: "my int( 1..31 ) $var" ? > >>>>> "JG" == Joe Gottman <[EMAIL PROTECTED]> writes: > > JG> Speaking of which, is there a run-time test to check if a variable is of > JG> integral type? Something like > > JG> print "date" if ($var is int) && (1 <= $var <= 31); > > the old standby is: > > int( $var ) == $var > I'm not sure if this works. my $var = "0"; # Notice the quotation marks print "is integer" if (int($var) == $var); In the above case int($var) == $var returns true when I would want it to return false. Joe Gottman
Re: "my int( 1..31 ) $var" ?
> "JG" == Joe Gottman <[EMAIL PROTECTED]> writes: JG> Speaking of which, is there a run-time test to check if a variable is of JG> integral type? Something like JG> print "date" if ($var is int) && (1 <= $var <= 31); the old standby is: int( $var ) == $var uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: "my int( 1..31 ) $var" ?
- Original Message - From: "Mr. Nobody" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 03, 2003 1:58 PM Subject: Re: "my int( 1..31 ) $var" ? > --- Smylers <[EMAIL PROTECTED]> wrote: > > Murat Ünalan wrote: > > > > > print "date" if $var is int( 1..31 ); > > > > I don't think that the type needs to be specified here, especially if > > the variable has already been declared to be of the required type, so a > > junction should be sufficient: > > > > print "date" if $var == any(1 .. 31); > > > > Smylers > > Superpositions in the core? You're kidding, right? > > What's wrong with "if 1 <= $var <= 31"? > For one thing they're not equivalent. my $var = 2.5; print "date" if $var == any(1..31); print "in interval" if 1 <= $var <= 31; Speaking of which, is there a run-time test to check if a variable is of integral type? Something like print "date" if ($var is int) && (1 <= $var <= 31); Joe Gottman
Re: "my int( 1..31 ) $var" ?
[EMAIL PROTECTED] (Damian Conway) writes: > > http://groups.google.com/groups?q=superpositions+group%3Aperl.perl6.language > > finds 141 articles. > > BTW, searching for "junctions" as well (i.e. the new name for the concept) > adds an extra 70 or so articles. Some of which are superimposed! :) Oh, and Mr. Nobody - if you still don't think it's been argued against properly, look at any one of my posts from those threads. :) -- > I never thought I'd say this, but you're getting very strange. Thank God: I thought it was everybody else. - J-P Stacey
Re: "my int( 1..31 ) $var" ?
Simon Cozens wrote: http://groups.google.com/groups?q=superpositions+group%3Aperl.perl6.language finds 141 articles. Thanks, Simon. BTW, searching for "junctions" as well (i.e. the new name for the concept) adds an extra 70 or so articles. Damian
Re: "my int( 1..31 ) $var" ?
Various folks wrote: Superpositions in the core? You're kidding, right? Nope. They're in (this week at least!) What's wrong with "if 1 <= $var <= 31"? ...nothing. If you like it, by all means use it. But, (1) TIMTOWTDI, (2) Smyler's version is more visually concise (although, granted, it actually takes a few extra chars), (3) Smyler's version puts the variable (the important thing in the expression) on the left instead of the in the middle, and (4) IMHO, Smyler's version reads better as English. 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 significant cost in this case. Wanting to do this for arbitrary lists dosen't need junctions. "if grep $_ == $var, @mylist" suffices. Except that it's much uglier (and hence less maintainable) than: if $var == any(@mylist) Moreover, in this case, junctions may well be faster, since they short-circuit and C probably still doesn't. Damian
Re: "my int( 1..31 ) $var" ?
[EMAIL PROTECTED] (Mr. Nobody) writes: > I looked through the p6l archives, there really wasn't much discussion about > it. http://groups.google.com/groups?q=superpositions+group%3Aperl.perl6.language finds 141 articles. -- An ASCII character walks into a bar and orders a double. "Having a bad day?" asks the barman. "Yeah, I have a parity error," replies the ASCII character. The barman says, "Yeah, I thought you looked a bit off." -- from Skud
Re: "my int( 1..31 ) $var" ?
--- Smylers <[EMAIL PROTECTED]> wrote: > David Storrs wrote: > > > On Fri, Jan 03, 2003 at 10:58:49AM -0800, Mr. Nobody wrote: > > > > > --- Smylers <[EMAIL PROTECTED]> wrote: > > > > > > > junction should be sufficient: > > > > > > > > print "date" if $var == any(1 .. 31); > > > > > > Superpositions in the core? You're kidding, right? > > Yeah, somehow they just slipped right in there without anybody on this > mailing list really noticing -- and certainly without any long threads > discussing the syntax for their operator incarnations and the knock-on > effect that could have on other operators ... I looked through the p6l archives, there really wasn't much discussion about it. > > What's wrong with "if 1 <= $var <= 31"? > > > > ...nothing. If you like it, by all means use it. But, (1) TIMTOWTDI, > > (2) Smyler's version is more visually concise (although, granted, it > > actually takes a few extra chars), (3) Smyler's version puts the > > variable (the important thing in the expression) on the left instead > > of the in the middle, and (4) IMHO, Smyler's version reads better as > > English. It's also far slower. Constructing a 31-element list, junctionizing it, then testing against each element vs. 2 numeric comparisons. I know where my money is... > Those are stylistic things, and to some degree a matter of taste. More > importantly the junction version -- or even better, the smartmatch > version as pointed out by Chris Dutton -- work for arbitrary sets, not > just ranges of consecutive values. Wanting to do this for arbitrary lists dosen't need junctions. "if grep $_ == $var, @mylist" suffices. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: "my int( 1..31 ) $var" ?
David Storrs wrote: > On Fri, Jan 03, 2003 at 10:58:49AM -0800, Mr. Nobody wrote: > > > --- Smylers <[EMAIL PROTECTED]> wrote: > > > > > junction should be sufficient: > > > > > > print "date" if $var == any(1 .. 31); > > > > Superpositions in the core? You're kidding, right? Yeah, somehow they just slipped right in there without anybody on this mailing list really noticing -- and certainly without any long threads discussing the syntax for their operator incarnations and the knock-on effect that could have on other operators ... > > What's wrong with "if 1 <= $var <= 31"? > > ...nothing. If you like it, by all means use it. But, (1) TIMTOWTDI, > (2) Smyler's version is more visually concise (although, granted, it > actually takes a few extra chars), (3) Smyler's version puts the > variable (the important thing in the expression) on the left instead > of the in the middle, and (4) IMHO, Smyler's version reads better as > English. Those are stylistic things, and to some degree a matter of taste. More importantly the junction version -- or even better, the smartmatch version as pointed out by Chris Dutton -- work for arbitrary sets, not just ranges of consecutive values. Smylers
Re: "my int( 1..31 ) $var" ?
Chris Dutton wrote: > On Friday, January 3, 2003, at 08:55 AM, Smylers wrote: > > > Murat Ünalan wrote: > > > > > print "date" if $var is int( 1..31 ); > > > > print "date" if $var == any(1 .. 31); > > I was under the impression the "smart match" operator would cover that > implicitly. Ah, yes; of course it does. > print "date" if $var =~ 1..31; > > Has this changed somewhere without my noticing it? No -- I just forgot about it. But now you bring it up, I do remember that the symbol changed, so I think it should be: print "date" if $var ~~ 1..31; Smylers
Re: "my int( 1..31 ) $var" ?
> Date: Fri, 3 Jan 2003 12:06:24 -0500 > From: Chris Dutton <[EMAIL PROTECTED]> > > On Friday, January 3, 2003, at 12:00 PM, Chris Dutton wrote: > > > print "date" if 1..31 given $var; > > Except that this would always be true. Nevermind, I'm an idiot. You're not such an idiot. You just got one word wrong: print "date" when 1..31 given $var; There is definitely postfix C. C, and C are postfix, so I don't see why C wouldn't be. Miko seems to want it enough. But, in accordance with Larry's "Nope, still can't chain [postfix conditions,]" this would not be very useful. Hopefully he'll reconsider whether you can chain them or not? :) Luke
Re: "my int( 1..31 ) $var" ?
On Fri, Jan 03, 2003 at 10:58:49AM -0800, Mr. Nobody wrote: > --- Smylers <[EMAIL PROTECTED]> wrote: > > junction should be sufficient: > > > > print "date" if $var == any(1 .. 31); > > Superpositions in the core? You're kidding, right? > > What's wrong with "if 1 <= $var <= 31"? My understanding was that junctions were most definitely in the core. As to what's wrong with the example you give...nothing. If you like it, by all means use it. But, (1) TIMTOWTDI, (2) Smyler's version is more visually concise (although, granted, it actually takes a few extra chars), (3) Smyler's version puts the variable (the important thing in the expression) on the left instead of the in the middle, and (4) IMHO, Smyler's version reads better as English. --Dks
Re: "my int( 1..31 ) $var" ?
--- Smylers <[EMAIL PROTECTED]> wrote: > Murat Ünalan wrote: > > > print "date" if $var is int( 1..31 ); > > I don't think that the type needs to be specified here, especially if > the variable has already been declared to be of the required type, so a > junction should be sufficient: > > print "date" if $var == any(1 .. 31); > > Smylers Superpositions in the core? You're kidding, right? What's wrong with "if 1 <= $var <= 31"? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: "my int( 1..31 ) $var" ?
On Friday, January 3, 2003, at 12:00 PM, Chris Dutton wrote: print "date" if 1..31 given $var; Except that this would always be true. Nevermind, I'm an idiot.
Re: "my int( 1..31 ) $var" ?
On Friday, January 3, 2003, at 08:55 AM, Smylers wrote: Murat Ünalan wrote: print "date" if $var is int( 1..31 ); I don't think that the type needs to be specified here, especially if the variable has already been declared to be of the required type, so a junction should be sufficient: print "date" if $var == any(1 .. 31); I was under the impression the "smart match" operator would cover that implicitly. print "date" if $var =~ 1..31; Has this changed somewhere without my noticing it? Hmmm... thinking about another form of the above, I wonder... is there a postfix version of "given"? print "date" if 1..31 given $var;
Re: "my int( 1..31 ) $var" ?
Murat Ünalan wrote: > print "date" if $var is int( 1..31 ); I don't think that the type needs to be specified here, especially if the variable has already been declared to be of the required type, so a junction should be sufficient: print "date" if $var == any(1 .. 31); Smylers
"my int( 1..31 ) $var" ?
I have an idea ! Damian conway's Attribute::Types suggests "my $date: INTEGER(1..31);" but i think "my int( 1..31 ) $date" is more like a c++/java "Integer date( 1, 31 );" and a weddig of both should fit perl6 best. Would mean: my int( 1..31 ) $var; $date = 23; # okay $date = 32; # KABOOM! I have some additional idea, when someone dislikes the tie-like behaviour: an explicit testing with print "date" if $var is int( 1..31 ); I think this suggestion should had been packed into a RFC, but when the RFC-process closed i was still in my perl baby-shoes. Murat
