My first post in a long time to p5p was on a thread about ideas for perl 5.12, a thread which got dragged off into the mad quagmire of adding XML libraries to perl core (a bad idea, and I wrote some of the ones being talked about being added).
Instead, I suggested that perl support a new keyword: "class". Which would allow you to write:
class Foo isa Bar, Baz {
my $x # instance variable
our $y # class variable
sub method {
# note no $self in here - we don't need it
$x = 1;
$y++;
SUPER::method(@_);
}
};
Now I remember talking to Artur at YAPC one year and he said this was eminently doable - you can have a class equivalent of lexical variables which would make access as fast as accessing a true lexical. But that might have been the beer talking, and I haven't done enough poking about the perl internals to know the truth. Certainly if you couldn't make this faster than a current perl "class" then it's not worth it.... 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.
Re:Rubyometer++
Matts on 2007-07-07T13:55:42
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.Re:Rubyometer++
chromatic on 2007-07-07T18:41:27
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.
Re:Rubyometer++
Matts on 2007-07-07T21:46:05
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.Re:Rubyometer++
chromatic on 2007-07-07T23:45:06
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 and instance variables subverts that.
Alternatively your way lies hungarian notation, which you're welcome to use.... or sigils in Perl 1 through 6,
$self->{variable_name}in Perl 5, and twigils in Perl 6.I note that Perl 6 takes this principle even further with invariant sigils as well as twigils to mark process global and environment scope.
Re:Rubyometer++
Matts on 2007-07-08T03:17:12
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.Re:Rubyometer++
chromatic on 2007-07-08T05:16:54
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 only end-user conventions to disambiguate different those scopes is the right approach. Try explaining the difference between instance variables and closed-over lexicals to a moderately skilled programmer who's never used closures before.
Re:Rubyometer++
perigrin on 2007-07-08T06:07:15
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 opaque objects
... private seems appropriate) ...and using the 5.10 "features" pragma idea we can keep backwards compat and/or scope this to only work inside a class{} block ... The point is to improve Perl5's OO speed, not to argue about the semantics of what that means. I'm all for anything that improves performance since I suspect ultimately it would be hidden behind a Moose API for me anyway.
Re:Rubyometer++
Ovid on 2007-07-09T09:16:47
In Perl 6, how do you tell by looking at a method name the difference between an instance and class method? (Well, internally it's easy, but externally, not so much. This is a problem with most programming languages.)
Aside from that minor quibble, I do agree with your point. Being able to easily disambiguate between these cases is important and relying on convention can be difficult. Programmers who don't grok OO will do stuff like this and then complain it's broken:
my $x;
class Foo isa Bar, Baz {
our $y; # class variable
sub method {
# note no $self in here - we don't need it
$x = 1;
$y++;
SUPER::method(@_);
}
};And how does a subclass grab $x and $y? There would need to be more sugar added. Still, if this is significantly faster, I'd be tempted. It might be better than nothing.