Re: Re: Perl Naming Conventions

Thanks for the link. Unfortunately the text describes only the basics.

I often OO modules on the CPAN which have the following style:

Methods:

get_value { ... };
set_value { ... };
[download]

Attributes:

my $foo = new foo(
   PrintError => 0,
   RaiseError => 1,
);
[download]

One example is DBI.

Now I'm wondering if this is a convention or just because the author of the module likes it.

Comment on Re: Re: Perl Naming Conventions Select or Download Code

Replies are listed 'Best First'.
Re: Re: Re: Perl Naming Conventions by halley (Prior) on Apr 28, 2003 at 19:51 UTC
If more than two modules do it, it's a convention. In all matters of style, "consistency isn't." That said, the convention of passing named pairs is pretty commonly used. Whether the names are capitalized or punctuated varies. Whether the pairs are stored as attributes, or invoke special features, varies. It's enough of a convention that I hear that perl6 will offer a couple new features for parameter-checking these named arguments. I'd say the get_ and set_ naming idea is more of a porting convention to be similar to languages that can't overload their methods. The style I proposed above wouldn't work in languages or libraries which couldn't distinguish the calling context or treat the arguments differently. -- `[ e d @ h a l l e y . c c ]`	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Perl Naming Conventions
by halley (Prior) on Apr 28, 2003 at 19:51 UTC

If more than two modules do it, it's a convention. In all matters of style, "consistency isn't."

That said, the convention of passing named pairs is pretty commonly used. Whether the names are capitalized or punctuated varies. Whether the pairs are stored as attributes, or invoke special features, varies. It's enough of a convention that I hear that perl6 will offer a couple new features for parameter-checking these named arguments.

I'd say the get_ and set_ naming idea is more of a porting convention to be similar to languages that can't overload their methods. The style I proposed above wouldn't work in languages or libraries which couldn't distinguish the calling context or treat the arguments differently.

--
[ e d @ h a l l e y . c c ]

[reply]