Mailing List Archive: Bricolage: devel

[Bricolage-Devel] Bric::_get

Index | Next | Previous | View Threaded

sam at tregar

May 31, 2002, 9:34 AM

Post #1 of 3 (304 views)
Permalink

[Bricolage-Devel] Bric::_get

Hello all. Can anyone think of a reason why Bric::_get can't be just:

sub _get {
my $self = shift;
return wantarray ? @{$self}{@_} : $self->{$_[0]};
}

Right now it's:

sub _get {
my $self = shift;
my (@keys) = @_;
my @return;

# Iterate through the keys and build up a return array.
for my $i (0..$#keys) {
# If this is a private field, we need to access it differently.
eval { push @return, $self->{$keys[$i]}};

if ($@) {
my $msg = "Problems retrieving fields";
die Bric::Util::Fault::Exception::GEN->new({'msg' => $msg,
'payload' => $@});
}
}

# Syntax sugar. Let the user say $n = get_foo rather than ($n) = get_foo
return wantarray ? @return : $return[0];
}

It seems to me there's no way that the "Problems retrieving fields"
exception could ever be triggered, as long as $self doesn't overload '{}'.
In my opinion, if we start overloading '{}' then we deserve whatever
errors result!

With the smaller function _get uses around 20% less time in my tests - ~6
seconds versus ~8. Not a huge win, but not insignificant either.

-sam

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Bricolage-Devel mailing list
Bricolage-Devel [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-devel

sam at tregar

May 31, 2002, 10:05 AM

Post #2 of 3 (288 views)
Permalink

Re: [Bricolage-Devel] Bric::_get [In reply to]

On Fri, 31 May 2002, David Wheeler wrote:

> I would say yes, do that, on one condition: keep the old version around, and
> enable it when DEBUG or QA_MODE or some such is enabled. Because you'll be
> relying on the presence of a constant, the other stuff will be optimized out
> at compile time, but can still be brought in when we run into problems:

Good enough for me. In fact, this may be a generally good strategy for
the work I'm doing now - skip some run-time tests in bottlenecks unless
QA_MODE is set.

Thanks,
-sam

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Bricolage-Devel mailing list
Bricolage-Devel [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-devel

david at wheeler

May 31, 2002, 10:09 AM

Post #3 of 3 (288 views)
Permalink

Re: [Bricolage-Devel] Bric::_get [In reply to]

On 5/31/02 10:34 AM, "Sam Tregar" <sam [at] tregar> claimed:

> Hello all. Can anyone think of a reason why Bric::_get can't be just:
>
> sub _get {
> my $self = shift;
> return wantarray ? @{$self}{@_} : $self->{$_[0]};
> }

I would say yes, do that, on one condition: keep the old version around, and
enable it when DEBUG or QA_MODE or some such is enabled. Because you'll be
relying on the presence of a constant, the other stuff will be optimized out
at compile time, but can still be brought in when we run into problems:

sub _get {
if (QA_MODE) {
my $self = shift;
return wantarray ? @{$self}{@_} : $self->{$_[0]};
} else {
# Original version.
}
}

David

--
David Wheeler AIM: dwTheory
david [at] wheeler ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory [at] jabber

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Bricolage-Devel mailing list
Bricolage-Devel [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads