Re: [PW-dev] Properties - object variables vs. accessors

[Stephen A. <ste...@of...>]

At 10:52 AM 6/11/2001 -0400, you wrote:
>I truly believe that we will end up going back and making all code use
>accessor functions.

All code *outside* the class should *always* use accessor functions.
The only question to be resolved is whether code *inside* the class
(i.e. in other methods of the class) must obey this rule also.
In other words, we treat each attribute as though it is "private".

I think that we leave the choice to whomever codes the class.

>I don't think this is a matter for the end developer but rather those who
>are trying to offer widget functionalities. If we want to have *flexibility*
>in how widgets function based on need - from very simple operation to very
>complex - we must take the necessary steps to allow for this.
>
>The example I raise is the one of multilingual text property. So, for
>example a label property for your widget. Now, most of you want one language
>and would make sense to store as a string:
>    $widget->{'label'}="First name";
>    sub label {
>        my $self=shift;
>        return $self->{'label'};
>    }
>
>Me? I've got something else in mind...
>    $widget->{'label'}{'en'}="First name";
>    $widget->{'label'}{'fr'}="prenom";
>    sub label {
>        my $self=shift;
>        my $lang=$self->container->user_lang;
>        if (exists $self->{'label'}{$lang}) {
>            return $self->{'label'}{$lang};
>        }
>        return $self->{'label'}{$self->container->default_lang; }
>    }

Exactly.

>So, any time in another method where you've got something like:
>sub html {
>    my $self=shift;
>
>    return "Your label is ".$self->{'label'};
>}
>
>It will work for the first simple case but not for the more complex case.
>
>sub html {
>    my $self=shift;
>    return "Your label is ".$self->label;
>}
>
>This works for both cases.
>
>Doesn't this make sense? I know you're trading preformance for flexibility
>but isn't that a stated design objective? Flexibility will take precedence
>over performance.

I agree with this.
Flexibility and Performance are both design objectives,
and Flexibility takes precedence over Performance (at least for now).

>Jay

Stephen