|
Re^3: Psychic Disconnect and Object Systems
by BrowserUk (Patriarch) on Apr 15, 2011 at 22:51 UTC
|
A real world example of a read-only variable which can't be recalculated on demand is your car's odometer.
Ignoring that in the real world, the DVLA might argue with that assessment. Clocking is still big business, though it is getting harder to do. :)
That is an example of both "Except for the rarely implemented concept of externally read-only attributes which are internally read-write." and an exception to "most times".
But even that belies the reality of (at least modern) real world odometers which can display in either miles or kilometres, but internally probably count output shaft revolutions. They might therefore be best modelled as an internal revolutions counter attribute with a pair of methods that apply an appropriate scaling factor to that attribute to produce the miles or kilometres figure.
Why not just count in miles and convert to kilometres on demand you might say. But back in the real world the same electronics in the dash are used in vehicles with multiple different drive trains. Eg. The BMW 3 series comes with 1.6, 1.8, 2.0, 2.5, 3.0 & 3.5 litres engines. You also have low-reving diesel and high-reving petrol engine options. Whilst the gear ratios will usually account for much of the difference in engine speed to road speed, they do not fit a rear axle capable of withstanding the rigours of 300bhp to the 120bhp 1.6 models, and the final drive ratios will be different. Adding to that, different models have different size rims and tyre profiles so the odometer has also to account for different rolling radii.
The upshot is, that they do not make a different odometers for each of these combinations of model to allow them to count directly in miles or kilometres, but instead count in some arbitrary revolutions of the input and then write different constants ("appropriate scaling factors") to ROM which are used to convert the counter to real-world measurements.
In other words, there are no getters or setters for the actual attribute; just methods to obtain calculated derivatives of that private attribute.
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.
| [reply] |
Re^3: Psychic Disconnect and Object Systems
by ikegami (Patriarch) on Apr 15, 2011 at 21:02 UTC
|
hum? My odometer changes all the time. You wouldn't use is => 'ro' for a car's mileage cause you wouldn't be able to change it as the car moves.
| [reply]
[d/l] |
|
|
Actually, you would. You do not want car odometers with some knobs that allows the driver to change the value. The external API of a car odometer does not have a setter - the driver can look at the display and see the value; he cannot set it. (Day trip meters are an intermediate - they allow display, and they have a reset function, but still, the driver cannot set it to an arbitrary value). Now, the driver can drive the car, and that will cause the attribute to change, but that's not setting a value of an attribute using a set-accessor.
| [reply] |
|
|
Now, the driver can drive the car, and that will cause the attribute to change,
No, not without an accessor it won't. Sorry, but in Moose you don't have that form of access control. Without accessors, the car won't be able to change the odometer either. Either you have methods to change the value or you don't.
package Car;
use Moose;
has odometer => ( is => 'ro' );
sub drive {
my ($self, $distance) = @_;
...can't update odometer...
}
1;
| [reply]
[d/l] |
|
|
|
|
|
|
Re^3: Psychic Disconnect and Object Systems
by Anonymous Monk on Apr 17, 2011 at 00:47 UTC
|
I think a better example is the "actual time". The actual time, is a constantly changing value, which is read-only. Except for those people who are allowed to insert leap-seconds.
| [reply] |
|
|
I think a better example is the "actual time". The actual time, is a constantly changing value, which is read-only.
That is no better example.
Application code, whether Perl or C/C++ or any other language, does not have direct access to the hardware timers that underlie real-time clocks.
Therefore, it makes no sense for an application class or object to have a "actual time" attribute. They may have an actual time method, but that will of necessity make a system call to obtain the value.
Even if the class we were discussing was a kernel system class, an "actual time" method would still not return a direct read of a read-only attribute. Clocks are volatile hardware counters, and they do not count in program usable real-time units directly. They count in something related to bus clocks, which vary from processor to processor, and even with the current energy saving or turbo boost states.
So, any "actual time" method is going to involve some conversion from hardware clock units to real-worlds units. In other words, it is going to be a derived value.
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.
| [reply] |