Paul wrote:
> --- Ruth Albocher <[EMAIL PROTECTED]> wrote:
> > > > create_unit(SDunit, 'SDunit_name');
in create_unit function:
my $self = shift;
my $type = shift;
my $name = shift;
my $unit;
$unit = $type->new(stuff...);
$self->{'units'}->{$name} = $unit;
> > >
> > > looks like a bareword -- does the script have warnings on, and is
> > > it using the strict pragma?
> > > I guess it could be a function call, but if so I think it'd have to
> > > be prototyped....?
> >
> > thanks. i guess it is a bareword.
> > (i just didn't know what they were till now, i'm new..)
>
> Not a problem, though barewords are bad. =o)
> To save headaches in the future, put quotes around it.
>
> On the other hand, is there an SDunit module? is there a statement in
> the program that says
>
> use SDunit; # maybe with more parameters?
>
> If so, then it's better to use the reference syntax:
>
> SDunit->create_unit('SDunit_name');
>
> Then it's a lot clearer what it's doing.
> Just be careful -- if there's no such module, the above syntax will
> cause lots of headaches.
>
> In any case, add this lines to the top of the code:
>
> use diagnostics -verbose; enable diagnostics;
>
> This will enable lots of explanatory code that will help you find
> naughty things like barewords, and in a lot of cases will tell you
> what's wrong with them and even offer suggestions on how to fix them.
>
> I would also strongly advise (once you get all the warnings that
> diagnostics give you cleaned up) that you also add
>
> use strict;
>
> to the top of this and every program. It will make the program slightly
> harder to write, but in return will make it *MUCH* more likely to run
> and do what you *meant* for it to do, and LOTS easier to maintain
> later.
>
> First, however, make sure you read
>
> perldoc perlsub
>
> until you understand creating lexical variable using my(), and
>
> perldoc perlsub
>
> until you understand package global variables. Using strict will force
> you to either predeclare variables or always reference them
> specifically by package. These are good thing, I promise, even though
> they will probably give you headaches the first little while if you
> aren't already familiar with them.
>
> But understanding that and using strict and diagnostics (and correcting
> until you get *NO* warnings of any kind) will make you a much better
> programmer. Honest. =o)
thank you!
(reading about strict..)this is exactly the kind of advice i was looking
for. :)
errr, about that SDunit.. there is in fact an SDunit.pm, but since
create_unit can be used by other unit types too it had to be a parameter.
in this case i would still want to quote it right?
one more thing, about global variables:
this code i'm maintaining does not have ANY global variables.
instead, some objects are used as singletons:
they are "my"-ed at their package, and the 'new' function creates a new
object only if one doesn't exist yet.
either way it returns $self, and anyone wanting reference to it will just
call 'new'.
is this a good way to do this?
why wouldn't i just use a global object the good old way?
thanks again
ruthie
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
