Re^3: Packages with subs using fully qualified class names, not always their own.

[roboticus]

karlgoethebier:

You're not wrong at all. Roles could be a good way to do it.

Generally I do it when:

• It's purely a one-off thing that I'm trying to solve, and don't expect to ever need it for the class again. A frequent case is when I'm debugging something complicated that relies on a little bit of inner state of the class and a custom "toString" function in the class for logging could give me the data I need to solve the problem.
• The class API isn't fully resolved and some of the implementation is a bit hacky. I don't want to expose the hackiness to the classes API but I need to get a problem solved. So I have no problem accessing the internals in an ugly fashion to make something happen, and let the class evolve normally without putting an ugly hack in the API that may be troublesome to remove later. (Such as when John Smith sees it and immediately uses it in production....)

I'm not saying it's a good/best practice, but that it sure is convenient.

Sorry for the long delay in replying. I've ignored my Chatterbox queue a bit too long, and now I'm trying to work through the backlog...

...roboticus

When your only tool is a hammer, all problems look like your thumb.

[karlgoethebier]

"...I'm not saying it's a good/best practice..."

Thank you very much roboticus for your kind reply and the good advice.

I'm convinced that simplicity is one of the hardest things to accomplish - in any metier.

And i think that the combination of Class::Tiny/Role::Tiny is very close to this magic "One Size Fits All" pattern AKA the Holy Grail ;-)

Best regards, Karl