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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • ... and that's not a good thing. How can you tell by looking at a variable name whether it's a lexical or an instance or a class variable?

    Twigils help in Perl 6.

    • If you don't know what a variable does or is for, why the hell are you using it?

      This is like people who argue that perl is line noise because they don't understand it.
      • If you don't know what a variable does or is for, why the hell are you using it?

        Please excuse me for not memorizing the name of every single instance variable and for not wanting to scroll up to the class declarations in every class I ever want to read.

        • It's not about reading it, it's about using it. If you're doing some coding and you're accessing a variable that you don't know whether it's an instance or a class variable then you've got bigger problems coding than your are showing concern for.

          Alternatively your way lies hungarian notation, which you're welcome to use.
          • It's not about reading it, it's about using it.

            I don't see the difference. I could quote SICP (programs should be written primarily for people to read, not computers) or Larry Wall (different things should look different), but one of my prime goals when I program is to write code in such a way that I can keep only the details of the local context in my mind, as much as possible.

            Having to flip back and forth throughout all of the enclosing scopes to figure out which variables are lexicals and globals

            • by Matts (1087) on 2007.07.07 22:17 (#56050) Journal

              I could quote SICP (programs should be written primarily for people to read, not computers) or Larry Wall (different things should look different), but one of my prime goals when I program is to write code in such a way that I can keep only the details of the local context in my mind, as much as possible.
              Well either way, the difference with my version is you actually have class local variables which work and aren't externally tweakable (compared to perl5). Nothing about my scheme makes it impossible to define variables in ways that makes it clear that they're class or instance variables. Use capitalisation if that makes sense (i.e. my $instance_var vs our $ClassVar) - it's simply an alternative to hungarian notation or sigils.

              I certainly think this is a pointless argument compared to the potential benefits of this idea.
              • If there's only one contraindication of design in Perl 5, it's that relying on people to do the right thing without providing any recommendation of preference leads to confusion.

                I'm all for opaque objects and a better syntax for them. Yet it's clear to me that the existing OO support in Perl 5 requires a lot of discipline. (It took several years for people to start to believe that opaque objects might be helpful, for example.)

                I'm just not sure that adding two new types of variable scopes while leaving

                • Okay why not use a twigil then?

                  Assuming it's too hard to take $. over (since perldoc perlvar tells me it's the current line number in the output filehandle and I know nothing about the perl parser and if we could distinguish between $.foo as a single statement and $.foo as some kind of strange global symbol followed by a function call probably illegal statement but hell this is Perl5 we're talking about)... why not $_? Traditionally this has been a "private" variable (and since you're already arguing for