software engineering, program construction

[ccc31807]

having globals (really static data in this case) isn't bad but
accessing them in a global way is bad and a very bad habit you need to
unlearn.
Okay.

STOP USING & for sub calls. this is true regardless of the globals!!

Why? What is the reason for an ironclad, absolute rule against using &
for user defined function calls?

your code is hardwired
to only use those variables and only be in that file with the
globals. do you see the difference? you will now argue that this code
will only live here. that is bogus as in other cases it won't stay there
forever. then you have to rewrite all the code. learn the better api
design now and practice it.

But what if it WILL only live here? What if it's a one time script
that you KNOW that you will only use once and then delete permanently?

descriptive names can lie.

That they can do!

you can't move the code as i said above.

This is also true, but it doesn't account for those occasions when the
code is guaranteed not to move.

that is true for all sizes of programs. you haven't demonstrated the
ability to code in that style and keep defending (poorly at that) why

Don't mistake 'defending' a position for the purpose of advocating it
with 'defending' a position for the purpose of testing it. Just
because a scientist attempts to falsify a hypothesis doesn't mean that
he doesn't believe that it's false -- he simply wants to test it. I'm
not advocating a particular style, just asking questions.

your global style is good or even better. it isn't good or better in any
circumstances. passing in the refs is much cleaner, more mainatainable,
more extendable, easier to move, easier to reuse, etc. there isn't a
loss in the bunch there.

QED

CC

 

[Uri Guttman]

c> Okay.

c> Why? What is the reason for an ironclad, absolute rule against using &
c> for user defined function calls?

it is documented in perlsub and covered in this group MANY times. rtfm
or google for it so i don't have to repeat it again. or you can trust
the group's knowledge that is it bad and also very old perl4 style. also
it isn't even needed anymore if you call subs with foo().

c> But what if it WILL only live here? What if it's a one time script
c> that you KNOW that you will only use once and then delete permanently?


c> That they can do!

c> This is also true, but it doesn't account for those occasions when the
c> code is guaranteed not to move.

that is NEVER a guarantee. learn that too. code moves. as i said, if it
doesn't here, it will in some other scripts. the bad habit needs to be
changed so you don't get bitten later.

c> Don't mistake 'defending' a position for the purpose of advocating it
c> with 'defending' a position for the purpose of testing it. Just
c> because a scientist attempts to falsify a hypothesis doesn't mean that
c> he doesn't believe that it's false -- he simply wants to test it. I'm
c> not advocating a particular style, just asking questions.

you are not testing or anything here. you are defending your poor habit
against a cadre of experts in perl. you come here for help and even
after repeated explanations you keep 'testing' it. that is called
defending with little to stand upon. it gets tiresome. just know that
you lower your ability to be hired by holding on to such poor coding
habits.

uri

 

[Jürgen Exner]

You didn't answer the question, or maybe I didn't make the question
clear enough.

If you have a large data structure that you need to both modify and
read (at different times), why make a copy of the data structure to
pass as an argument to the function only to return the copy to
overwrite the original? In other words, why do this:
my %data;
%data = get_data(%data);
%data = modify_data(%data);

or this:
my %data;
get_data(\%data);
modify_data(\%data);

when you can just as clearly do this:
my %data;
&get_data;
&modify_data;

Exactly because it is not as clear.

I for one am totally mystified why on earth you are passing @_ to those
functions explicitely without ever using it while at the same time you
are passing the actual data behind the back in global variables.
This is like setting the left turn signal and then turning right.

You do not have to dig in obscure documentation because you can see
clearly what the function is doing by the descriptive name. Also, I
guess I want to stress that this is a specific script for a specific
purpose, a special purpose tool as it were, and not a general purpose
script that applies to a general problem. FOR THIS LIMITED PURPOSE I
just don't see the point of passing an argument either by reference or
by value.

I agree that for more substantial programs for a more general purpose
that the principles expressed (about variable localization, passing
identifiable arguments, returning specific values, etc.) are best
practices.

Fine, then why not practise those everywhere. Only practise makes good
coders. And if you practise poor style ....

jue

 

[Jürgen Exner]

Why? What is the reason for an ironclad, absolute rule against using &
for user defined function calls?

Do you know what '&' does? Do you need that functionality or take
advantage of that functionality? If the answer to either question is
'no', then don't use it, because it does something behind your back
without you knowing what it does. And that will bite you badly one day.

But what if it WILL only live here? What if it's a one time script
that you KNOW that you will only use once and then delete permanently?

And the moon is made of green cheese ....

Anyway, good style requires constant practise. Constant practise of good
style, of course.

jue

 

[Uri Guttman]

JE> And the moon is made of green cheese ....

really? then we don't need to send food for any future manned missions
to the moon. maybe we can mine it for supplying food to mars
missions. does cpan have a module for dealing with moon cheese?

uri

 

[Martijn Lievaart]

JE> And the moon is made of green cheese ....

really? then we don't need to send food for any future manned missions
to the moon. maybe we can mine it for supplying food to mars missions.
does cpan have a module for dealing with moon cheese?

Moon::Cheese obviously.

M4

 

[William R. Mattil]

for my $key (sort keys %$hash) {
my $person = $hash{$key};
print $OUT qq("$person->{name}","$person->{id}"\n);
}

Ben,


This fails to compile on my Unix system perl v5.8.0

Global symbol "$hash" requires explicit package name at ./perl.pl line 62.
Global symbol "%hash" requires explicit package name at ./perl.pl line 63.


Did I get it wrong ?


Regards

Bill

 

[Uri Guttman]

WRM> This fails to compile on my Unix system perl v5.8.0

WRM> Global symbol "$hash" requires explicit package name at ./perl.pl line 62.
WRM> Global symbol "%hash" requires explicit package name at ./perl.pl line 63.

ben made some minor errors in his untested code. it looks like he meant
to use $data which is passed a hash ref from the main line code. so that
code should be (untested again):

for my $key (sort keys %$data) {
my $person = $data->{$key};
print $OUT qq("$person->{name}","$person->{id}"\n);

note that i also changed the second line to $data-> since it is a ref
and not a hash.

uri

 

[William R. Mattil]

WRM> This fails to compile on my Unix system perl v5.8.0

WRM> Global symbol "$hash" requires explicit package name at ./perl.pl line 62.
WRM> Global symbol "%hash" requires explicit package name at ./perl.pl line 63.

ben made some minor errors in his untested code. it looks like he meant
to use $data which is passed a hash ref from the main line code. so that
code should be (untested again):

for my $key (sort keys %$data) {
my $person = $data->{$key};
print $OUT qq("$person->{name}","$person->{id}"\n);

note that i also changed the second line to $data-> since it is a ref
and not a hash.

uri

Uri,

Thank You

Regards

Bill

 

[William R. Mattil]

Yes. Thanks for the correction.

Ben

Ben,

Thanks for posting the code in the first place ..... it was very
straight forward for the most part and easy to understand.


Regards

Bill