in reply to Frivolous function names

Personally I probably wouldn't create two different methods for this, as other posters have observed practically any names you come up with could be misunderstood or end up being so long as to be unweildy. Instead I would create one sub that took a parameter to indicate if it should autovivyfy or not, something like 
use constant CREATE_IF_NOT_EXIST=>1;
use constant NO_CREATE=>0;
sub get_foo {
    my $flag=shift || 0;
    #.....
}

my $obj=get_foo(CREATE_IF_NOT_EXIST);
my $obj_or_undef=get_foo(NO_CREATE);

[download]
IMO this makes for cleaner and easier to document and remember code. You could even make it die if the sub does not get a parameter, forcing the client to always call it with an appropriate param.

Yves / DeMerphq
--
This space for rent.

Replies are listed 'Best First'.
Re (tilly) 2: Frivolous function names
by tilly (Archbishop) on Dec 06, 2001 at 18:35 UTC
    Ironic. While offering me advice on how to avoid having any ambiguous names, you have hit on a horribly ambiguous name that I would never leave in code.

    One of the most common programming errors - and a hard one to see - is to reverse the meaning of a flag. For that reason I consider any flag horribly misnamed unless the name is a yes/no question which its value is an answer to. For instance your flag might be appropriately named $will_create. Do that and you will stop making that particular mistake again.

[reply]
[d/l]
      I admit I didnt take a lot of time to write my code snippet as my point was to avoid naming problems and use a flag. The choice of name for the flag variable would be the authors call. Although on second thought I wouldnt use $will_create but probably $create_on_demand

      Anyway, point well taken though, in future Ill put more thought into variable names in my snippets...

      :-)

      UPDATE
      <bad_excuse>
      On second thought there is a point here actually. You were talking about externally available names, whereas $flag while poorly named is internal and thus less of an issue. This isnt to say that $flag was a good name, it is not. But there is more room for error in internal use code than external use code, especially if said variables/code are properly scoped. </bad_excuse>

      Yves / DeMerphq
      --
      This space for rent.

[reply]
[d/l]
[select]
        I call that a really bad excuse.

        Flipping flags in internal code is an incredibly easy and common error to make. There are some estimates suggesting that it is actually more common than off-by-one errors - but not as often caught because it is much harder to see the error. (According to legend I heard the very first Fortran compiler made this error - the flag determining whether to compile carefully or not was reversed. No idea whether that is true.)

        As far as I am concerned the entire question of whether summon/get is OK is much less important than getting flags reversed. As matters stand, I don't think people would accidentally call summon, and most of the time get is right. But flipping flags is a basic error that you will make again and again...

[reply]

In Section Meditations