Front page | perl.perl5.porters |
Postings from November 2008
demerphq wrote:
> Operators may not have side effects. CANNOT have side effects.
> Operators also MUST ALWAYS return the same result for the given
> inputs. -X "operators" satisfy neither requirement.
That's no definition of operator I've ever heard. Certainly not in Perl.
Abigail points out a pile of operators (I'll throw in qr//, qx// and m//) that
have side effects. And then there's the fun of operator overloading!
> In reality operators and true functions are indistinguishable except
> by syntax conventions. But perls "functions" are rarely true functions
> as they a) dont return the same value every time, and b) very often
> have side effects.
While I understand your argument about "functions" not having side-effects, I
think you're splitting hairs on the wrong head. Making a stand for the purity
of the definition of "function" in Perl is a bit futile. Perl is a language
of side-effects. Using "has side-effects" vs "does not have side-effects" as
your distinguishing trait.. well, you're going to have a lot of things in one
bucket.
More importantly, it's not a particularly useful distinction from a
documentation point of view. Documentation is not about enforcing
proscriptive definitions. Documentation is about users finding what they
need. And I don't think most Perl users use that definition of operator and
function.
Part of the reason I asked is to find out what sort of stretched logic one
might come up with to justify the current layout, and highlight it's lack of
utility for documentation purposes.
The most obvious answer, if it's useful at all to keep them separate, is still
"wordy thing" vs "symbol-y thing".
--
94. Crucifixes do not ward off officers, and I should not test that.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/