Another feature I think belongs in this list (and is related to AUTOLOAD) is symbol-table manipulation. It's very cool, but should be avoided in most situations. (Yes, I know that a lot of stuff is done via symbol-table manipulation, but that's using the API.) tie is another feature that, imho, belongs in this category.

I agree on both of these items as well. And while personally I do like mucking around with the symbol table, I try to do with great respect for the power it gives me and not to abuse it for the sake of just being clever. As for tie, I have only ever used it once, and much like my uses of AUTOLOAD, there was not other way to accomplish the same thing by other means.

I'm not arguing for a Java- or VB-ification of Perl. I'm arguing for some self-discipline among Perlers.

I don't take your statements to be that at all, I see your case as one for rational restraint and only going to war,.. ahem I mean symbol tables/AUOTLOAD/tie if you have to.

Should I use the published API or muck about in the internals?

I've been thinking about this for a couple of days now, to give sanity the chance to overrule my insanity, but it hasn't.

sub AUTOLOAD{}, $AUTOLOAD and tie are as much APIs as use base;, @ISA and bless.

Both sets of function employ symbol table manipulation and 'magic'. You're being selective about which set you choose to ordain and which you choose to deprecate.

I'm not arguing for a Java- or VB-ification of Perl.

Actually, I think you are.

I'm arguing for some self-discipline among Perlers.

This sounds like the same argument as that put forward by those who vote to enforce helmet laws on motorcyclists, even though they have never ridden a motorcycle. The phrase that comes to mind is "The nanny state".

Yes, they are a part of the API, just as much as symbol-tables are ... depending on how you define "API". I'm not talking semantic quibbles here, but a real difference between definitions.

I'm not choosing to "ordain" or "deprecate" anything. I have a personal line in the sand, and I do understand that the line is my line and only my line. That line is the API line. If I cross it, I am mucking about with the internals.

Unlike Java or VB, the API line isn't the Berlin Wall, made of concrete and topped with concertina wire. It's a line with lots of gray areas - it's actually more of a "zone" than anything else. It's a zone that, IMHO, one should enter only upon careful consideration of the benefits and drawbacks. It's the zone that, in my experience, separates those who sling Perl code and those who understand Perl programming.

Now, if you choose to cross that zone, you (hopefully) are conciously desiring to have some of the restraints and limits lifted. It's no coincidence that you usually have to disable at least some portion of strictures to muck about on the other side of the API zone.

It's also no coincidence that code written on the other side of the zone is almost never self-documentable. This is the code you spend 2-3 hours in a code review explaining how the darn thing works and you end up with a decent lecture on some portion of the Perl internals. I'm talking about the Damian side of the world. You know, the modules he writes, then puts in the documentation under BUGS something like "There almost have to be some bugs in code this funky."

Not every use of any feature I would mark as being beyond the zone qualifies. But, for every simple usage, one can think of two usages that aren't so simple. That's why it's not a hard-and-fast line; it's a zone.

As for your last comment ... I was arguing for self-discipline. If you want to go ahead and muck your own application up, that's your own damn fault. I don't have to maintain it, so I couldn't care less. I don't want to be involved in how you do your code.

What I was arguing for (and which was completely unobvious) was changing how the community through docs and sites like this present these capabilities. We already strongly dissuade people from using symbolic references, a feature I think most of us would consider beyond the API zone. Why should it be any different for AUTOLOAD, symbol-table manipulation, tie, and other, similar features? We can argue about which features and sub-features truly belong in that zone, but I would hope we agree that there are certain areas newbies shouldn't enter, for their own sanity. The Llama book doesn't discuss AUTOLOAD, save in very general terms - that's saved for the Camel. Same with tie, eval, and s///e(e(e)). No-one complains about that ...

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Note that if your criteria for the zone is whether it is discussed in the Llama book, then implementing objects is beyond the API zone. And indeed, for many people who use Perl, that is!

These personal lines truly are personal. While many people will agree that certain things are over the line, many others will not.

Incidentally I personally think that AUTOLOAD should be treated with more caution than manipulating the symbol table. In particular if I want a bunch of accessors I'm more inclined to create them by typeglobbing some closures, thereby leaving the sledgehammer of AUTOLOAD unused and available for a bigger problem if needed.