Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re: Make $^V and "my" implicit

by Tux (Monsignor)
on Feb 03, 2014 at 17:13 UTC ( #1073233=note: print w/ replies, xml ) Need Help??


in reply to Make $^V and "my" implicit

The only part I like about your suggestion is to use $^V, but not in the way you suggest.

use 5.16.2; (or whatever version) is *shorter* than what we used to type: use strict;, but with the additional benefit that we now implicitly have all the new features available and we do not need to declare that we want to use the say keyword or whatever new shiny feature you like.

What I can imagine as a syntax to just use everything the current perl version happens to feature is something like:

#!/usr/bin/perl; use $^V; use warnings;

While we're at that: that new syntax might as well be geared directly to the lazy (it is a virtue right?) and imply use warnings;.

You could suggest that to the perl5-porters mailing list and see what they think.


Enjoy, Have FUN! H.Merijn


Comment on Re: Make $^V and "my" implicit
Select or Download Code
Re^2: Make $^V and "my" implicit
by gunzip (Monk) on Feb 03, 2014 at 17:23 UTC
    I'm coming from a different position in that I resent having to "enable" the features of the Perl version I'm running. I don't see anything like this in other languages.

      There is a real issue in breaking existing programs. The perl5 porters weigh heavily in backward compatibility. You don't want all your existing scripts to die because one of the new features makes your existing code die. E.g. let me assume you have a functuntion called say, not entirely unlikely. By declaring to use the new features the current perl offers you, you now have to think everytime you see that funtion if that is the sub from you or the one that is enabled by your request to get all new and shiny whatever.

      For short scripts, one-liners and scripts that only use core-stuff and very basic things, it might not matter, but then you'd already be happy with just stating the obvious use strict;. It is a choice the porters made: enabling new shiny features in a rather easy way contra breaking existing code by just enabling new syntax.

      An additional opportunity is now handed to you to test your code without breaking it. Testing is good. I've been in QA quite a while now, and I must say that perl is one of the few languages where testing is one of the first subjects mentioned when they say where a language is good in. Funny I never hear that for python, and I hear people praise junit, but not using it as much as they should for java.

      Personally I resent some "features" being enable by default in even low-level languages like C. GNU started enabling // comments long before C99 made this a standard. Any idea how many programs now cannot be compiled on machines that have VERY EXPENSIVE ANSI-C compilers that comply to C89? That causes hate and grief. I'm glad not to see that in perl, and if shit like that happens, I get an opportunity to turn it off (most of the time) and I get warned well in advance that a change will happen.


      Enjoy, Have FUN! H.Merijn

      "I don't see anything like this in other languages."

      I can't use C++ range-based for loops, lambda expression syntax, variadic templates, uniform initialization, move semantics, or any other C++11 feature with my GNU compiler unless I specify -std=c++11 to the compiler. The reason, I suppose, is to avoid the potential for silently breaking old code by changes in keywords, syntax, and semantics. One might say that it would be better for the GNU compiler to default to C++11, and allow a command line switch to revert to older syntax/semantics. But then all old code would have to have its makefile updated, or it would run the risk of becoming broken.

      This is the same principle at work with not, by default, enabling features to Perl that introduce newer keywords or semantics. Just because you haven't seen it in other languages doesn't mean it doesn't exist in other languages, and doesn't disqualify it as a "least dangerous" way to upgrade while avoiding damaging legacy code.


      Dave

        OK, I should have said the languages I've looked into (Ruby, Python, Erlang, Clojure, Elixir, Javascript, Scheme, Lisp) get by without version strings specified in the code.

      > I don't see anything like this in other languages.

      I do. To use C99 data-types in code that I compile with my favourite complier* I need to provide the -c99 flag on the command line.

      * spelling deliberate. I use it because it's very picky about correctness and standards compliance.

Re^2: Make $^V and "my" implicit
by gunzip (Monk) on Feb 03, 2014 at 17:31 UTC
    I'm not suggesting replacing version strings with "use $^V;" as in your code. My beef is more with the whole boilerplate phenomenon which seems to be absent in other languages.

      My beef is more with the whole boilerplate phenomenon which seems to be absent in other languages.

      hahaha

Re^2: Make $^V and "my" implicit
by tobyink (Abbot) on Feb 03, 2014 at 23:41 UTC

    In what circumstances could...

    use $^V;

    ...possibly be useful?! You really want a script that imports 5.16 features when it's run under Perl 5.16, and 5.14 features when it's run under Perl 5.14?

    The new features in Perl 5.16 are 'unicode_eval', 'evalbytes', 'current_sub', and 'fc'. Does your script use those features?

    • Yes: then use v5.14 is not sufficient, so use $^V is not sufficient when run under Perl 5.14. So you should explicitly write use v5.16.

    • No: then use v5.16 would be overkill, so use $^V is overkill when run under Perl 5.16. So you should explicitly write use v5.14.

    use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

      I didn't mean it literally so should have written it as

      use <version string>

      I disagree, though. If whatever new version of Perl is installed on my machine I should not have to manually enable its new features.

        Generally speaking, you don't need to manually enable new features. Recent features like the defined-or operator (// and //=), and s///r, and the package NAME BLOCK syntax, and so on, work out of the box in new versions of Perl. You don't need to explicitly enable them.

        The exception to this rule is for things like state, say, fc, and so on, which before becoming new Perl features, were already syntactically correct Perl. Thus people could have been using functions with these names already. Enabling them implicitly would break existing Perl scripts, thus they need to be enabled explicitly.

        use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1073233]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (12)
As of 2014-09-18 20:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (124 votes), past polls