Re^4: Serious Exporter Problems

Let's see.

You ignored the alternate require solution. You ignored the error reporting issues with BEGIN type games which argue for not playing them. You dismiss the existence of languages that don't handle circular dependencies. (I believe that PL/SQL is one.) You don't seem to be aware that your solution doesn't solve all of the issues with circular dependencies in Perl. (Example, suppose in your example that a Patient has claims, and a claim has a Patient. Both of those are cached for efficiency. Guess what? You have a memory leak!)

As for your example, there are plenty of ways of handling this. For instance you can have a module that you're supposed to use which does all of the other uses for you, in the right order. Or you can use an OO style which avoids the need to export anything and makes circular dependencies not quite as bad. Or you can use lazy loading so that dependencies are resolved as they're about to be called. And often you can find a design which avoids the circular dependency entirely. (Rule of thumb, in a good design each module will call few others, but will be called from many other places. If this is achieved, then circular dependencies become unlikely.)

Any of these solutions can be sufficient. All of them avoid having to think hard about compile vs runtime. All of them avoid the error reporting problems that I pointed out can happen with BEGIN games.

Given the existence of alternatives, I'd prefer to not make recommendations that make code more complex and cause problems of their own for the possibility that someone will create grief. Instead I'd prefer to suggest the discipline of avoiding creating circular dependencies, and then let people know what problems they create when you do cause them.

Comment on Re^4: Serious Exporter Problems

Replies are listed 'Best First'.
Exporter Problems - solved by PetaMem (Priest) on Jul 11, 2005 at 08:03 UTC
tilly, you are one of the most experienced monks here at the monastery and from not only the number of your posts but also their content one can be quite sure, that your "highscore-position" here pretty much correlates with your perl skills. I do not know what previous issues you might have had with etcshadow, but I'd like to look at this thread without considering them. If I do, I see on the technical side very many precious facts and alternatives to our problem, on the other side I see many IMHO unnecessary attacks against etcshadow. Sure, the BEGIN "solution" might bring complexity to the code and later on even more subtle problems that'd be absolutely hard to tackle. OTOH we took his advice "put everything into BEGIN" more lika a rule of thumb exactly as yours "every module should load a few modules and be loaded by many". In fact etcshadows advice was the first answer that came in and it contained a real solution for our problem. The system compiled again within minutes. it was good for us, because it gave us something to think about, as this was a blind spot in our design. Before we had an attitude "perl is great it will handle this somehow" - even circular references. Hell it worked for more than five years! by thinking about it, we were able to deduct the "badness of circular reference" even before your post came in. In short, his answer was valuable for us. By providing your comments on that matter, we got everything one can only hope for - a thorough and detailed view on this matter. We see both contributions as valuable, perhaps even the value comes only with some argues, but let me state, that some of your formulations remind me of merlyn when he - undoubtedly also a perl capacity - got beaten by seemingly being too harsh in his comments. Bye PetaMem All Perl: MT, NLP, NLU	[reply]
Re: Exporter Problems - solved by tilly (Archbishop) on Jul 11, 2005 at 13:45 UTC
I haven't had previous problems with etcshadow. But I hate it when people give categorical advice that I think is bad, particularly when they know full well that very competent people disagree with them! If you know that people disagree with you, understand the disagreement and respect it. Sure, go ahead and offer the advice but make it clear that it is what you personally like to do. Don't take the attitude, This is what everyone should do and I can't believe that some experienced people have been stupid enough to argue with me. That's guaranteed to not sit well with any experienced person who does not agree with you. Which is what happened.	[reply]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks