|
•Re: How about class Foo {...} definition for Perl?
by merlyn (Sage) on Jan 17, 2004 at 23:38 UTC
|
| [reply] |
|
|
| [reply] |
Re: How about class Foo {...} definition for Perl?
by chromatic (Archbishop) on Jan 17, 2004 at 23:20 UTC
|
I also use this to introduce Perl developers that don't know very well OO in Perl, but know in Java, to the OO development, since everything that we develope need to be in OO style.
What's the benefit of using Perl then? You might as well use Java.
Any good developer should be able to pick up the syntax — and idioms — of a different language fairly soon after he understands their relationship to the actual concepts.
With that said, I do like the approach of writing out the generated files instead of running the filter on each invocation. Sometimes that kind of code generation works out really well.
| [reply] |
|
|
| [reply] |
|
|
I don't think it will have that effect, though. If I understand you correctly, you have two groups of people: those who understand OO Perl and those who don't — and the latter group understands OO Java.
Your proposed solution is to create a third language, so that the second group of people don't have to learn OO Perl. So now you have people in three groups: those who know OO Perl, those who know Java-ish OO Perl, and those who know OO Java. The first group may be able to debug the generated code, if they know the Java-ish language. None of the other groups would.
Me, I'd just teach everyone who needs to write OO Perl OO Perl.
Update: But you must teach them something now! Why put an additional step in there?
| [reply] |
|
|
|
|
Re: How about class Foo {...} definition for Perl?
by hhdave (Beadle) on Jan 17, 2004 at 23:34 UTC
|
The syntax seems fairly nice and more like 'standard' OO
One problem I see with this sort of thing, though, is that without completely parsing the whole filtered source file there are ways in which to confuse it. I had a quick look at the source code and it seems that if you were to put some of the things which the filter is replacing (eg the sub declerations) inside a quoted string they would still be replaced even though they clearly shouldn't. I know this is not likely to happen normally, but it would be a nasty gotcha if it did.
It all comes down to the difficulty in parsing perl. I did something which involved inventing a bit of new notation for perl once. It worked ok, provided I avoided anything which would confuse it. It suffered this same problem though.
| [reply] |
|
|
FILTER_ONLY( all => \&filter_html_blocks , code => \&CLASS_HPLOO , all
+ => \&dump_code ) ;
Soo, I take care about quoted strings! ;-P
Here's a valid code:
use Class::HPLOO ;#qw(dump) ;
print "class null { sub n { 1 } }\n" ;
class Foo {
sub test {
print "test>>@_\n" ;
print " sub fake { 2 } \n" ;
}
}
Generated code:
print "class null { sub n { 1 } }\n" ;
{ package Foo ;
use strict qw(vars) ;
sub new {
my $class = shift ;
my $this = bless({} , $class) ;
my $ret_this = $this->Foo(@_) if defined &Foo ;
$this = $ret_this if ( UNIVERSAL::isa($ret_this,$class) ) ;
$this = undef if ( $ret_this eq '0' ) ;
return $this ;
}
sub test {
my $this = shift ;
print "test>>@_\n" ;
print " sub fake { 2 } \n" ;
}
}
Graciliano M. P.
"Creativity is the expression of the liberty".
| [reply]
[d/l]
[select] |
|
|
| [reply] |
Re: How about class Foo {...} definition for Perl?
by hardburn (Abbot) on Jan 18, 2004 at 01:20 UTC
|
I feel about this the same way I feel about all auto-generated class modules: if you already understand OO Perl and you happen to like the module in question, then go ahead and use it. Just as importantly, you should know the limits of the module so you know when to ditch it (just like any other tool). Personally, I would avoid Class::HPLOO simply because it relies on source filtering, which is always messy. If you can come up with a non-filtering solution with reasonable performance, I might use it.
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l] |
|
|
Do you have some idea of how to make this without filtering, and without rebuild Perl?
I suse Filter::Simple, and this is not very stable, since is very easy to break the syntax, specialy the place holders that Text::Balanced uses, that accept any char from 0 to 255, what will mess with the code if you have to much place holders, since you start to get #, @ , $ , @ , % in the code.
I have fixed the problem using my own place holder over the previous place holder, but this is a hard work.
Other fixes were made, because Text::Balanced also mess with q|qq|qr|qw|qx|tr|y|s|m! Well, I'm trying to make the best work here and test it a lot!
Graciliano M. P.
"Creativity is the expression of the liberty".
| [reply] |
|
|
It'd be difficult to get exactly the same syntax without a filter. A subroutine named class with a prototype of (@&) could get you part way there. It could be called like class 'Foo' extends => qw( Bar Baz ) { . . . };.
Instead of using the builtin sub definition, you could create a new subroutine named method with a prototype of ($@&) which could be called as method method_name => ('$attr1', '@attr2', '%attr3') { . . . };. This would then generate the regular Perl subroutine.
I probably got the prototypes wrong, as I don't usually have a use for them.
Alternatively, you can do what everybody else is doing: wait for Perl6 :)
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l]
[select] |
Private rant
by l3nz (Friar) on Jan 19, 2004 at 09:59 UTC
|
I know you'll hate what I am about to say, but I find Perl 5's OO syntax rather ugly. Looks better with your module, but you still have to write classes full of $this->{X} and my $this = shift; that are a nuisance - mostly if compared to the rest of the language and its overall elegance. With your module, the syntax is rather similar to PHP's objects, and it's frankly better than Perl's (no pun intended - really).
Am I the only one feeling that Perl syntax about objects is awful? I believe a language should primarily be a tool to think in, and then a way to tell a computer to do things. I'd better not think in Perl 5 objects....
| [reply]
[d/l]
[select] |
|
|
"...Looks better with your module, but you still have to write classes full of $this->{X} and my $this = shift; that are a nuisance..."
You don't need to declare my $this = shift, Class::HPLOO will handle it automatically for you. About $this->{x}, yes, you still need to use it and any filter that tries to handles scope variables and global variables as an object attribute wont work very well!
But note that OO is much more than just a syntax, and Perl is one language that let us to know exactly how OO is build, what let us to build it like we want.
Graciliano M. P.
"Creativity is the expression of the liberty".
| [reply] |
please don't
by doug (Pilgrim) on Jan 19, 2004 at 16:12 UTC
|
What if you get a file that you'd rather not change, but would like to modify. Or can't change because it is read only on a network file system. In some file that you can edit you can simply use a package statement and you can extend the existing class. I've used this technique to override code that I've gotten from CPAN. I forget the details, but I didn't like how Getopt::Long::configure() was working, so I added new methods to Getopt::Long that did what I needed *without modifying the original or breaking compatibility*.
I know that real solution to this is version control (I'm a ClearCase admin by day), but sometimes a quick and dirty proof of concept hack is easier. And for a one-of like this, why track a change that affects no one else?
- doug | [reply] |