in reply to Checking for Valid Dates

It is hard for me to believe that perl would not have a built-in isvalid operator to test for the validity of dates, but the llama book doesn't mention one and neither does my google search.

You are correct: Perl does not have an is_valid operator or function for dates, and such a thing does not belong in the language (IMHO), but in a library (like Date::Manip or Date::Calc), or even in the standard Time::Local module (which doesn't have a simple is_valid function, but you could create one with it). Also, Date::Manip is rather slow, the author of it even suggest that 90% of the time you probably want to use one of the other date/time modules -- you might consider using Date::Calc instead.

I am also curious why there is an ampersand in &parsedate. I was not aware that variable or function names can begin with an ampersand.

The ampersand is largely a holdover from perl4 times when that was how you invoked a subroutine (just like scalars, arrays, and hashes had their own type specifier, so did subroutines). There are a few differences when ampersand is used compared to when it is not used: 

&func;  # calls func with current contents of @_
        # no prototype checking

&func() # calls func with no args, no prototype checking

[download]

see the perlsub manpage for more details.

Replies are listed 'Best First'.
Re: Re: Checking for Valid Dates
by tune (Curate) on Jan 05, 2001 at 04:02 UTC
    Altough the ampersand is not mandatory, I use it, in order to read my code easier. In my opinion it belongs to the structured perl programming style.

    -- tune

[reply]
[reply]

      Altough the ampersand is not mandatory, I use it, in order to read my code easier. In my opinion it belongs to the structured perl programming style.

      I would disagree. I think it is clumsy, confusing, needless and potentially problematic:

      From perlfaq7:

      What's the difference between calling a function as &foo and foo()? 

      When you call a function as `&foo', you allow that
function access to your current @_ values, and you by-pass
prototypes.  That means that the function doesn't get an
empty @_, it gets yours!  While not strictly speaking a
bug (it's documented that way in the perlsub manpage), it
would be hard to consider this a feature in most cases.

When you call your function as `&foo()', then you do get a
new @_, but prototyping is still circumvented.

Normally, you want to call a function using `foo()'.  You
may only omit the parentheses if the function is already
known to the compiler because it already saw the
definition (`use' but not `require'), or via a forward
reference or `use subs' declaration.  Even in this case,
you get a clean @_ without any of the old values leaking
through where they don't belong.

      Tony

[reply]

        Yes and no. Some of that is correct, some of it is misleading. I humbly suggest you read (tye)Re: A question of style which I think clears up some of this.

        It is particularly unfortunate that the FAQ suggests using "foo()" since all-lowercase function names is the one case where I can recommend using "&foo()". It also overlooks the real potential for good error checking by intentionally leaving off the parens (for functions with mixed-case names).

                - tye (but my friends call me "Tye")
[reply]

In Section Seekers of Perl Wisdom