Re^2: Closure objects with public, private, and protected fields

I feel I should be allowed to get myself into as much trouble as I want, even if it's something very dumb and avoidable.

If the people who caused the problems were the same people who had to fix the problems, I might agree with you. :-) That's not always (often?) the case. I hate it when the person currently working on a project assumes that they will be the only person ever to work on the project. Especially when the person who ends up being asked to "just make it all work" when the person leaves the company is me. :-(
--
Ytrew

Comment on Re^2: Closure objects with public, private, and protected fields

Replies are listed 'Best First'.
Re^3: Closure objects with public, private, and protected fields by spiritway (Vicar) on Mar 07, 2006 at 05:34 UTC
I feel your pain, and you've raised a good point. I've never worked on any sort of programmning team or project, so I've never had to clean up code, nor have mine cleaned up. I have come back to my own code after a few months, only to find that whatever flash of genius allowed me to create it, was no longer with me, and it was about as readable as Sanskrit ;-).	[reply]
Re^3: Closure objects with public, private, and protected fields by Anonymous Monk on Mar 06, 2006 at 23:32 UTC
Sure it sucks to have to fix someone else's code because they didn't read the documentation, but it also sucks to be physically restrained from doing something that is perfectly logical simply because the author of an object never conceived that you'd use his object in that particular way. Perl isn't the type of language that caters to the lowest common denominator, so in my book flexibility trumps idiot proofing.	[reply]
Re^4: Closure objects with public, private, and protected fields by adrianh (Chancellor) on Mar 08, 2006 at 11:12 UTC
flexibility trumps idiot proofing True. But wouldn't it be nice if we could have both?	[reply]
Re^5: Closure objects with public, private, and protected fields by Anonymous Monk on Mar 08, 2006 at 19:17 UTC
Sure it is, but restricting access to code within a module means you've lost flexibility. However, you do get both to some extent by using something like the _variable convention. You are told what you should be doing, but aren't forced to do it. To me, that is sufficient idiot proofing. I don't think its in society's best interest to protect really determined idiots.	[reply]
Re^6: Closure objects with public, private, and protected fields by adrianh (Chancellor) on Mar 09, 2006 at 10:44 UTC
Re^4: Closure objects with public, private, and protected fields by Anonymous Monk on Mar 07, 2006 at 19:20 UTC
Sure it sucks to have to fix someone else's code because they didn't read the documentation, but it also sucks to be physically restrained from doing something that is perfectly logical simply because the author of an object never conceived that you'd use his object in that particular way. If you're clever enough to outhink the module author, surely you're clever enough to extend his module to cover your reasonable and well thought out usage pattern? so in my book flexibility trumps idiot proofing Flexiblity is comparatively easy; idiot proofing is very, very hard. ;-) Ask anyone who's tried to keep small children (or cats!) safe; it's harder than it sounds sometimes. -- Ytrew	[reply]