Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Why Should I Program in $Language? 24 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Did I hear in my vague readings of p5p that this might be possible in 5.12?

    If so, it'd be SO nice to have:

    class Foo isa Bar {
      method init(%options) {
        $self->{some_key} = $options{some_key} // "default";
        ...
      }
    }

    • FYI, MooseX::Declare provides exactly that already (except you inherit with "extends", not "isa").

      • Yeah I know, but it's very heavyweight (brings in Moose).

        • Plain Perl OO is also very heavy, it brings in perl and entire OS. Are you sure that bringing in Moose is a legitimate concern, or are you just afraid to look at something popular out of fear that it might turn out to be better than complaining?

  • We have a better object system than you do! Just install Moose (but be aware that it might have backwards-incompatible changes in a few months)

    What changes in a few months? I am not aware of such plans. We are generally highly responsible about our backwards incompat changes. Changes happen and sometimes they are hard and ugly, this is the real world after all and they need to happen. But ...

    I suspect your just being sarcastic and playing the devils advocate here. Your right, having a decent object s

    • Yes, I am being a bit sarcastic, but more than once we've not been in a position to update Moose on our BBC project because of Class::MOP (and this has happened with Catalyst, too). The most important Perl projects and the ones we depend on are the ones we have difficulties keeping up with. Even if you rarely change Moose, or Class::MOP, or Catalyst, or [insert favorite module here] with backwards-incompatible changes, then you have to consider the chance of said changes happening in all of them, not just

      • Yeah I know, I still have servers running Moose 0.24, so I am with you. We have been discussing trying to make these things smoother in various ways so that people can upgrade and say, get a performance improvement, but opt out of a feature/API change. Similar to the use feature in 5.10. It is still not perfect, but it might help ease those of us (me included) who have to deal with production environments all the time and for whom upgrading it usually not an option.
    • I'd be happy with a decent object system that is not in core if it didn't require half of CPAN as prerequisites. Here at work, I have yet to be able to resolve all of the dependencies. As soon as I get a minute or two to spare (wishful thinking really), I might actually be able to track down the troublesome module(s).

      • It shouldn't take too long since you only have 16 [cpantesters.org] non-core dependencies to go through. FWIW, I am pretty sure there are more then 32 modules on CPAN now, it has grown a lot in the past few years ;)

        Sorry, couldn't resist. But in all seriousness we would be happy to help with this either on IRC or the Moose mailing list. The biggest problem I have seen when installing Moose on a bare bones system (and yes I have done it many MANY times so I am empathizing and not mocking) is that we require more up to date

        • Stevan, I just don't have the bandwidth to deal with it right now. As soon as things slow down here to only a relatively hectic pace then I'll try it again.

        • I bit the bullet today and finally got Moose installed.

          I installed the prereqs one by one starting from the bottom of the list. Once I thought I had them all installed, I tried to install Moose and it couldn't find about five of the prereqs so I bailed.

          I tried to install each of them again only to be told that four of the five were already installed. Class::MOP just did not want to install... Or so it seemed.

          I traced the problem to the order of my include paths. Once that was fixed, Class::MOP and Moose ins

  • but the answer is simple to me. Because it's alot easier to code in PHP. You just need a standard hosting package somewhere and you'll have PHP. If you need a script being installed, just drop it somewhere in the webspace and tada - it's running. You don't have to put it in special locations like cgi-bin, just drop it somewhere. Yep, it's a sad thing - I'll stick with Perl. Which seems to be something which can't be understood by the PHP people around me....but they are starting to understand..

    • It is simple to configure to run .pl as perl for Apache. But I prefer security of cgi-bin. It means that none will be able to download my non-executable files like templates or data files.

  • sub setHiddenInNavigation {
      my ($this, $hideInNavigation) = @_;
      $this->{hideInNavigation} = $hideInNavigation;
    }

    really isn't any worse than the PHP version. Sure, you gain an extra line, but you 'sub' is shorter than 'function', and you can lose the 'return' and 'public'. So, less typing overall.

    • What happens if you call it with 17 arguments? A signature can guard against that. Second, what happens if you misspell the hash key? You may or may not get an error at that point, but have it happen later on (if at all). PHP's version will have a failure when calling a non-existent method. (I also hope that PHP's syntax allows validation rather than blanket assignment, but I don't know it well enough.)

      • What happens if you call it with 17 arguments? A signature can guard against that.

        You'd expect that to be the case, but it isn't in PHP. PHP actually handles that exactly like my Perl version---it ignores the extra 16 arguments. That's how PHP implements variable numbers of arguments. So, PHP's method signature's have fooled you.

        Second, what happens if you misspell the hash key? You may or may not get an error at that point, but have it happen later on (if at all).

        This is indeed one drawback to the use of hash keys for object variable storage. But... PHP does the same thing. It'll happily create that variable for you on assignment.

        (I also hope that PHP's syntax allows validation rather than blanket assignment, but I don't know it well enough.)

        Not sure if its been added in PHP5, but 4 didn't.

  • Was that all pretty much just saying "we need an object system in core?"

    +1 for sentiment, but we need more than sentiment. We need a plan that p5p supports. (And, probably, a long-term feature branch in the core to prototype, test and get buy-in around.)

    As for the toolchain footnote, you're right, which is why I'm working on things like this [dagolden.com] and this [dagolden.com]. It can get better and it will get better.

    -- dagolden [dagolden.com]

    • Was that all pretty much just saying "we need an object system in core?"

      We need an object system and function/method signatures.

      We need a plan that p5p supports.

      I have no idea how to create this.

      • The function/method signature issue is very problematic because part of that deals with the philosophy of Perl. I, for example, sometimes find that static binding (compile time) of methods would make some problems magically go away, but I doubt that Perl 5 will ever be able to support that. Of course, signatures also might imply multimethods. That's another issue which would give people fits. Should all methods be multimethods or should we have to specify this directly?

        • Here's a secret, though: Perl 5.12 or 5.14 or whatever doesn't have to support all of those features to have useful function/method signatures. Even supporting only required positional parameters is useful for some 80% of extant code.

        • Considering all of this stuff already works in Perl 5 and is limited to a given lexical scope, I am having a really hard time seeing how this is 'impossible'.

  • The 1999 standard added common table expressions, and the 2003 standard added window functions. Those made it Turing complete.

    See http://assets.en.oreilly.com/1/event/27/High%20Performance%20SQL%20with%20Postgr eSQL%20Presentation.pdf [oreilly.com] for details.

    • That is cool. I was used to calling them analytic functions from Oracle, and googling for "analytic functions" and PostgreSQL only brought up posts from people wanting them in PostgreSQL. Now that I know that they're "window functions" they're easy to find:
      Window Functions [postgresql.org]
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.