|
in reply to This is why I use Perl
Question, if yer just going to generate accessors for every single property, why not just make them public? |
Re: Re: This is why I use Perl
by pg (Canon) on Nov 08, 2003 at 08:03 UTC
|
Good question.
If you allow, let me answer it by giving a simple example. Say we have a class that represents date, for example 2003-11-07, and one of its property is month.
- If I make this property public, someone uses this class, can easily set month to 13. Well, this could be well valid for some calendars, but not for this calendar that most of us use. So we opened up a hole for error by make it public. To avoid this error, we have to implement the checking logic in every single piece of code uses this class.
- Now if we make it private, and in the setter, we check whether month is less than or equal to 12, we only need to implement this logic once for good.
| [reply] |
|
|
In some languages (eg Ruby) this isn't a good reason since it is trivial to implement get/set methods that will be visible and manipulatable outside of the class exactly how the old attribute was. So you can start with every property public, and then fix ones which in retrospect shouldn't have been. So you don't worry about it until you have to.
You can do the same in Perl if you are willing to retrofit a tie on an existing class. (Admittedly at a considerable speed hit.) This is sufficiently obscure and confusing that the decision to do it is certainly making demands on the maintainance programmer.
I don't know Java well enough to know whether this strategy is possible there, but I strongly doubt it. (Corrections or confirmation welcome.)
| [reply] |
|
|
Disagreed.
To me this is not about the ability or capability of a given language, but about the principles of encapsulation, OO programming and the best practice for OO programming. You don't do things that's doable, if they are not the best practice.
| [reply] |
|
|
|
|
|
|
| |
|
|
|
Example: first we set day to 30. All is well. Next we set month to 2. All is still well, except that the 30th of February isn't valid.
Let's do it the other way around: currently the month is set to 2. We try to set day to 30, but the system won't allow it, because the 30th of February isn't valid. We were going to set the month later, you bozo system!
Lesson to be learned: don't let the system do your thinking.
I don't like overzealous range testing for each individual field, in this example because the ranges themselves are interdependent. Having a get/set interface won't help one single bit.
Instead, I only want the system to check if the date is valid, when I'm trying to use the date (in case of a Javascript on a HTML form: when trying to submit the form). In perl, for often used checks, you still can have some speed boost by caching, either by checking if the date has changed since last time, before checking again, or some use of a Memoize cache on the function value.
| [reply] |
|
|
No, you don't. Check-when-setting is to check-when-using as a compile time check is to a run time check. We want as much as possible of the former, so we get alerted when the problem happens, rather than hours later when any connection to its source is lost.
What you describe, however, is a case of a stupid interface. The problem you described occurs when you want to set several parts of the data structure, but the steps are checked for validity separately. The answer is there needs to be a way to signal that a series of changes is atomic. In this case, if you are doing this in Perl, it can be achieved very easily by offering a method like
$foo->set_date( day => 30, month => 2 );
Designing good interfaces is hard but very fundamental.
Makeshifts last the longest.
| [reply]
[d/l] |
|
|
the ranges themselves are interdependent.
If fields are interdependent, don't you want to have a
setter for all the fields, not just one field?
| [reply] |
|
|
