Re: const correctness

in reply to const correctness

First off, Perl has Readonly and constant which provide the same functionality. And, every single (usable) OO framework on CPAN allows you to specify accessors as separate from mutators, should you so choose.

Now, to some commentary.

Proper objects don't give you access to their state. That is a first-order violation of encapsulation. If you're peeking and poking at internal state, you don't have an object - you have a data structure with behavior. This is no better than the OO provided by Javascript. While I'm a fan of the prototype style of OO, it's not very useful from a sanity perspective.
I understand the sanity perspective when dealing with constants. But, I gotta tell you - I've been coding Perl for almost 13 years now and I have yet to run into a situation where I needed constants. The fact that I have never used Readonly and don't reach for constant in my own code should be telling. Frankly, I tend to use some sort of configuration object that exposes appropriate values through methods (not accessors!) and takes its initialization from some sort of config process (file, commandline, %ENV, etc). This is what DBM::Deep does and it works quite nicely.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re: const correctness

Replies are listed 'Best First'.
Re^2: const correctness by fergal (Chaplain) on May 14, 2008 at 13:56 UTC
Perl has Readonly and constant which provide the same functionality. They're not the same thing. const is not about constructing immutable values it's about being able to declare that "in the following code, the contents of this variable should not be modified, if you see me trying to modify it, throw a compile-time error". It's also about making a promise in your API which the caller knows will be kept because it has been checked at compile-time. Of course you can force the compiler to let you break the promise using a cast but it can't happen as an unanticipated side-effect or typo.	[reply]
Re^3: const correctness by BrowserUk (Patriarch) on May 14, 2008 at 14:47 UTC
In compiled languages, its also about giving the compiler clues about optimisations it can safely perform, especially in multi-threaded environments. A const value can be safely shared without locking, or moved into a register and not re-read for every reference. The current big problem is the lack of transitivity of const. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^2: const correctness by amarquis (Curate) on May 14, 2008 at 14:00 UTC
When first I learned programming in a formal environment (first computer science classes), I was very concerned about properly noting my "never to be changed" variables to the compiler. When I got to Perl, it was one of the first things I looked for, but was confused by the differences between and the possible subtle traps within Readonly and constant. So, I stopped using them, even though it bothered me to do so. And today my own thoughts are more in line with your point number two. My own code makes obvious what should not be changed internally, and the external interface protects/hides everything from outside code. I like giving myself as much protection against myself as possible (strict, warnings, etc.), but now feel like const would be redundant with the checks implicit in the way I code.	[reply]

In Section Meditations