Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Trying to make perl suck less again

by EvanCarroll (Chaplain)
on Dec 22, 2007 at 17:06 UTC ( #658664=perlquestion: print w/replies, xml ) Need Help??
EvanCarroll has asked for the wisdom of the Perl Monks concerning the following question:

OK, so in my quest to make Perl suck even less, I'm trying to hack in the ability to turn on v5.10 features with the usage of Moose, but only If perl is 5.10.

I'm not sure how to do this. Any ideas? The trick is you don't want Moose to be v5.10 only, but you want Moose to use feature ':5.10', if the version of the perl interpreter is v5.10+. This is tricky, because this information is known at compile-time, but I'm not sure how to do a compile time conditional that invokes the necessary 'use', to put the interpreter in 5.10 mode. When I was playing around with it a require wouldn't suffice.

The goal is simple to eliminate the need to use features ':5.10' all over the place. I realize the downside of this: upgrading interpreters has a higher probably of breaking v5.8 code (which is possible anyway).

Thanks in advance, one day Perl will suck even less.

Evan Carroll

Replies are listed 'Best First'.
Re: Trying to make perl suck less again
by ysth (Canon) on Dec 23, 2007 at 02:41 UTC
    feature is a lexically scoped pragma; there is no way (nor should there be) to turn it on everywhere.

    But to enable it in every module that uses Moose is easy: just add feature->import(":5.10") if $] >= 5.010; in Moose::import, the same as is done for the strict and warnings pragmas (sans conditional). And a use if $] >= 5.010, "feature", ":5.10"; at the top of

    But this seems like a silly thing to do; I presume the real Moose distribution won't integrate a change like that, for the same reason that features aren't automatic in the first place: backwards compatibility.

    It would make more sense to have a module of your own used by everything you write that loads both Moose and 5.10 features (untested):

    package EvanPerl; use strict; use warnings; use Moose; use if $] >= 5.010, "feature", ":5.10"; sub import { feature->import(":5.10") if $] >= 5.010; goto &Moose::import; # can't just call Moose->import since it need +s to know the "correct" caller. } 1;
      Moose doesn't have to be backwards compatible, and quite frankly it is stupid perl is to such an ape shit insane extent - especially being Perl 6's state. If you use Moose, the package that includes Moose should use 5.10 features. It is the very job of Moose's to eliminate cruft, after all -- it's just regular perl code, that makes perl more bearable. Having to tell Perl your code isn't retardedly esoteric, and thus can use new features, is surely an easy target for Moose. And v5.10 broke stuff anyway right? Without going into the minor things I'm sure it broke, it removed the deprecated pseudohashes...

      IIRC the strongest reason to keep Moose out of the CORE amongst other stupid modules that compete to make perl-suck-less, was that Moose wanted to develop at a higher speed than that of CORE, and that people acknowledge it might break backwards compatibility.

      Every few major releases of Moose have broken something, somewhere for me. However, I waste substantially less time finding and fixing them than I did hitting my head over retarded design decisions that predate Moose. And more often than not, the new functionality Moose includes with every major release quickly laps the amount of time I waste when Moose is broken from upgrade.

      Ignore those that would stifle development because they refuse to risk breaking compatibility. programmer_conservatives--

      Evan Carroll
        Thanks for explaining. I didn't know Moose regularly breaks compatibility. That's a little scary, if (as I believed to be the case) it is used by a number of CPAN authors, all of whom will be upgrading on their own schedules. Oh well.

        Update: the above was intended to be sarcastic. I assume that even if Evan's assertion that Moose has broken BC is true, it was accidental, not intentional.

Re: Trying to make perl suck less again
by perrin (Chancellor) on Dec 22, 2007 at 19:12 UTC
    It doesn't sound like a good idea to me, but I would try one of these:
    eval 'use feature q(5.10)'; # or require feature; feature->import('5.10');
      Uh, nice.

      PS -- I don't ever throw away bath water.

      Evan Carroll
Re: Trying to make perl suck less again
by Burak (Chaplain) on Dec 22, 2007 at 20:33 UTC
    how about:
    BEGIN { if ( $] < 5.010000 ) { # also set some bool var like $NEW_PERL $INC{''} = 1; package feature; } } use feature ':5.10';

      Is there room for a backported on the CPAN then?

        feature is clearly stolen from python, and is called future there.

        Perl is now always several steps behind.

Re: Trying to make perl suck less again
by Cop on Dec 22, 2007 at 17:20 UTC

    If I am reading this correctly, it sucks today.

    Why go through all this trouble, why not just move away?

      All software sucks. Some programs just suck more than others.
       - far too many posts in alt.sysadmin.recovery to count

      Judging by the use of English in some of your posts, Cop, I tend to suspect that it may not be your native language. There is no shame in that, but it may have left you unaware of this particular use of "even":

      In EvanCarrol's post, he says he wants Perl to "suck even less". This construct indicates that he believes it to already suck very little, but wants to remove the small amount of suckiness that remains. It could also be taken to imply that he believes Perl already sucks less than any of the other alternatives. It is not a complaint about the quality of Perl, but rather an acknowledgement that, as good as it is, it's still not perfect.

        You got that "even" correctly in terms of language, and I don't dispute that - yes it is about comparason. But you didn't get it correctly in this context - in terms of logic.

        You thought that "even" came into the picture when he was comparing perl against some other languages, but I take it that he was comparing this new version of perl against previous versions. The author never specified that, although I knew where he was heading.

        Then what he meant was that this new version sucks, although sucks less than previous versions.

        By the way, someone said in private that this is troll against troll. Now does this not mean that whoever said that took Evan's original post as troll - which means quite a few suspected that he was talking against perl? You know where this is leading to, right?

        All software sucks... say you are right, but there is always a level thing here, and perl is in the left field.

        The need for Moose is a clear indication how perl OO sucks. OO should be a built-in part of the language, not as some sort of add on. We all know that.

      It doesn't fully meet his needs. Tossing out the baby w/ the bathwater isn't always the right thing. In this case, a lot of value he sees in 5.10 is offset by a little inconvenience. He's trying to make it optional is all.

      It's why we have tailors for adjust suits, and car manufacturers can add features after the factory gives them a car.

        Who is the baby, and what is the bathwater? That's the basic question we all have to answer.

        The baby is whatever the project that people work on, and the bathwater is the technology that they pick. The whole and holy purpose is to use the technology to solve real world problems in scope of the project - certainly not to solve the problems with the technology picked. Pick the right technology, you only need to spend minimum amount of one's time on serving the techenology; while picking the wrong techonology, for example perl, you are forced to spend a big chunck of your effrot serving perl - to suffer, and subsequently less to no time to make the project right - to fulfill the real world requirements the best.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://658664]
Approved by friedo
[pryrt]: 1nickt, sprintf "%.16e", $v will always give enough precision to see 1 ULP (the smallest fractional part) of a standard 64bit Perl NV*
[pryrt]: (*: for systems where $Config{nvsize}==8 )

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (14)
As of 2017-05-24 19:07 GMT
Find Nodes?
    Voting Booth?