>>>>> "SR" == Stephen Reppucci <[EMAIL PROTECTED]> writes:
SR> On 12 Sep 2002, Uri Guttman wrote:
>> >>>>> "SR" == Stephen Reppucci <[EMAIL PROTECTED]> writes:
>> >> $self->{'fh'}->print( $text ) ;
>>
SR> Directly accessing members of your object??? Ewww...!
SR> Who invited you into my living room? ;^)
>>
SR> I know this is bordering (stomping?) on the pedantic, but wouldn't
SR> '$self->print($text);' be a clearer way of doing this?
>>
>> pedantic and wrong. :)
>>
>> $self is not a handle but contains a handle and other info as well.
>> that is a line from within a write() method in the Stem::Log::File
>> class.
SR> No, $self isn't a "handle" (if by handle, you mean filehandle), but
SR> it *is* an object ref, right? It seems silly to me to store the file
SR> handle in the object, but then access it directly -- there oughta
SR> be a method 'print' that knows about the fh.
there is missing context. that IS in a write() method already. it is
printing its data to a log file but it does other work as well.
sub write {
my( $self, $text ) = @_ ;
$self->{'fh'}->print( $text ) ;
$self->{'size'} += length( $text ) ;
my $rotate_options = $self->{'rotate'} ;
if ( $rotate_options &&
$self->{'size'} >= $rotate_options->{'max_size'} ) {
$self->_rotate() ;
}
}
so the filehandle is just another attribute of the object and it is
perfectly fine to access it directly here. if i used it more than once
in this method i would have assigned it to $fh and used that.
SR> Of course, now that you've given us some context (it's being called
SR> within the class, so you're not in *my* living room, we're looking
SR> in the window at what you're doing in *your* living room...;^),
SR> yeah, that's more acceptable. But unless you're *really* on the TomC
SR> side of "don't use objects 'cause there's a performance cost", then
SR> I maintain that using a method when one's available is not only
SR> valid, but has benefits.
i have been on both sides of that fence and still am. OO has its place
and it is not for all programs and projects. for stem it makes a major
difference and i chose to make it very OO. for smaller programs and
projects i tend not to use OO.
SR> E.g., what if you decided to change this class to provide a buffered
SR> (internally buffered within the object, not buffered like stdio...)
SR> implementation? If you use those as file handles all over the
SR> place, you've got to go hunt down all of the places you do so, and
SR> change them. If you've just used the 'print' method, that's all you
SR> have to change.
but this is the print/write method. there has to be some time you stop
calling methods and do the real work. :)
SR> Again, I can buy either one (inside the class, not out...), I just
SR> think if you're writing perl, the performance difference between the
SR> two doesn't matter, and you should favor clarity.
that is what i do. i don't worry about speed too much anymore. buy a
faster machine is often the best and cheapest solution to speed
issues. one key feature about stem is that you can split any application
in it to multiple machines with almost no effort. so adding more cpu
power is easy. so i don't focus on speed. in fact i have almost never
benchmarked it. it is designed for ease of coding and configuration. and
OO is a help in that area. i am giving a talk at LISA in november and i
plan on offering it at the october meeting so you will see more on how i
use OO in stem. the title is the stem cookbook.
uri
--
Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
_______________________________________________
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
