Please bottom post...
> Great, thanks for the detailed response. I have read the docs several
times,
> but each time it becomes a little less clear...
>
> I like the extra braces because they look pretty in syntax-highlighting
> editors. I am always using strict. Not sure what the second call was
or what
> looked weird about it, but it works.
>
Interesting, the syntax highlighting I use in Vim makes them look
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.
Specifically I meant, ${params{'server'}}; But now that I am actually
paying attention those are {} instead of () which makes that a hash
index rather than a sub call, I was thinking symbolic refs were creeping
in there, but they aren't. (See what I mean about readability with
extra unneeded punctuation).
> By fully qualified I meant writing Net::SMTP::method() (which I
generally do
> to make it easier to read (for me at least), copy and paste code), as
opposed
> to just method().
Fully qualified is ok (and needed in some instances) but make sure you
know the difference between,
Net::SMTP::method() and Net::SMTP->method()
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?
>
> 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? 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
b. How would you test such a dependency?
http://danconia.org
<snip old posts>
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
