On Sun, 13 Feb 2011 14:58:21 +0100, David Golden <xdaveg@gmail.com> wrote: On Sun, Feb 13, 2011 at 5:10 AM, Christian Walde <mithaldu@yahoo.de> wrote: I do not think it is a good thing for a technical documentation to start talking about style concerns. I'd prefer it if it would stick to concerns that actively deal with what the machine actually executes. i generally agree, with a few specific exceptions. (1) perlpolicy defines the terms "deprecated" and "discouraged". As these have specific meanings, they should be used when appropriate. Note that "discouraged" has a much stronger meaning than "not recommended". (2) Security. I think it is appropriate to recommend more secure ways of doing things, such as three-argument open() (3) Portability. If there is way to do things more portably without a downside, it should be noted. (4) When there is a clear "old way" and "new way" and the old way has clear downsides, but the old way has not been deprecated for the sake of backwards compatibility. Bareword global filehandles might fall into this category. Indirect object notation could be a close second, but I suspect would be more debatable. I find myself agreeing with all of these exceptions, though that might be because i think all of these are technical concerns in some way. Even discussing indirect versus direct seems worth it in such documentation, since indirect notation can lead to code being executed that was never intentended to be executed. The same can't really happen when using EXPR map syntax, right? -- With regards, Christian WaldeThread Previous | Thread Next