|Do you know where your variables are?|
Re^2: $foo->bar = 14;by adrianh (Chancellor)
|on Jan 03, 2003 at 14:08 UTC||Need Help??|
I think the aversion to using lvalue subroutines is cultural
Not in my case :-) I came to perl after doing a lot of coding in Pop-11 and I still miss its "updaterof" idiom.
I would like being able to do $o->foo = 12 in my perl modules. It makes it explicit when a method is a mutator without the noise of having separate setter/getter functions.
Unfortunately (in my opinion) the perl implementation of lvalue subs is near useless since it exposes the object implementation - making it harder to change your module
Yes, you can put in bad data, yes you can break things, but putting rubber pads on the edge of all of your functions does not make them safe.
Nothing can make your code 100% safe :-) Having assertions on arguments, etc. can certainly make it a lot safer. It can cut development time on larger projects by a silly amount - because you get sane errors close to the location that caused them.
It's just defensive programming, which in many cases is dangerous if over-done.
I agree, but I see it under-done a lot more than I see it over-done.
However, the point I was trying to make wasn't about checking arguments - it was about exposing the implementation of your class.
For example, consider a hypothetical object that can be readable, writeable or locked. With an :lvalue based API you would have something like this:
Now, what happens if (for whatever reason) I want to change the underlying implementation of these attributes to use a bitmask. You either have to change your API - or create some ghastly hack with tie. This is what I mean by an over-exposure of your object's implementation.
With a traditional single accessor/mutator or separate setter/getter methods - no problem.
As far as I can tell, lvalue works fine now, and when it's replaced with something better in Perl 6, which surely it will be, then there's no reason not to upgrade.
Hmmm... I wonder if you could do something sane now with the aid of tie and some source filters.... I'll have to have a think when I get some spare time...
One could just as easily argue that Perl 5 is experimental. Your points 1, 2, and 3 all apply to the same degree.
Got to disagree with that completely. They do not apply to the same degree. Experimental features break on a regular basis (threads, some of the regex stuff, etc.). Core perl has been very solid - due to lots of care and attention by the wonderful development peeps. I've had perl4 scripts run on 5.8 without a single change.
The 5.8 release especially has had a lot of time spent on a very nice test suite to prevent regression problems.
Update: Cleaned up the English a little.