On Thu, 1 Jul 2004 11:14:51 -0600, Wiggins d Anconia wrote
>
> non-descript. Definitely a lot of extra punctuation that would be more
> difficult to read for me and an easy way for syntax errors to creep
> in, but to each their own.
Interesting - I have found that the extra braces actually reduce my syntax
errors (similar to never putting a variable inside a double-quoted string,
since the perl compiler won't find typos until runtime). But I agree, to each
their own - hopefully I won't have to maintain your code and of course mine
meets all current and potential future/emerging requirements with no bugs so
no one will ever have to maintain mine.
> Fully qualified is ok (and needed in some instances) but make sure
> you know the difference between,
>
> Net::SMTP::method() and Net::SMTP->method()
Nope, I don't really know the difference and in fact I would expect these to
be equivalent. I don't think I would ever do either though - I think I would
instantiate an object and call the methods on that.
> Usually I would have thought you would have used,
>
> $smtp = new Net::SMTP;
> $smtp->method;
>
> Since I believe Net::SMTP is OOP, could this be part of your problems?
This is what I do - where did you see me do something else? The code is a mix
of OO and static/procedural, and I always fully qualify both. For instance,
my ${smtp} = new Net::SMTP( ${server} ); #OO
or:
my %{results} = IWAPI::SysUtil::run( -cmd => ${cmd} ); #static
> > As far as the compiler warnings, if I have module a which uses b and
> module b
> > that uses a and I perl -c one of the modules I get warnings about variable
> > redefinition.
> >
>
> Gotcha, are they exported variables?
No. I don't see much value in exporting - maybe another thing I should
research. It's not like Java where I can define a variable or method as
public. In fact the whole OO paradigm in Perl is a little nutty to me, though
I do see value in it. Also, the modules may each have my variables by the
same name - I wonder if that could be the issue.
> There seems something fishy
> with a design setup where a needs b and b needs a, seems like there
> ought to be a c in there such that b needs c, a needs c, but c needs
> neither a nor
I agree but I couldn't figure out how to resolve it.
> b. How would you test such a dependency?
Not sure what you mean by test - I use the code every day and it works, it's
only perl -c that objects.
Anyway, my core issue has been resolved - I always need to explicitly either
use or require any module I access from my script. Thanks a lot for your help.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
