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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I truly believe that we will end up going back and making all code use
accessor functions.

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; }
    }

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.

Jay

----- Original Message -----
From: "Gunther Birznieks" <gu...@ex...>
To: <per...@li...>
Sent: Sunday, June 10, 2001 9:46 PM
Subject: Re: [Perl-widget-developer] Properties - object variables vs.
accessors

> I think that I prefer the 2nd strategy first. It is possible that it is
> necessary to go back and recode to support inheritence. However, there is
> something that has been overlooked here.
>
> Inheritence is probably not the way most people will deal with widgets. I
> would posit based on my prior experience is most cases of widget reuse
> involves a has-a rather than is-a relationship -- a containment issue.
>
> So if I write a DateTime widget, it would have a date widget and a time
> widget but usually not inheriting from Date widget and then adding Time
> functionality.
>
> Of course, there are cases where inheritence is useful. I am not saying
> they don't exist. But in my experience with writing widgets for JSPs, I
> have almost never had to resort to inheritance.
>
> At 12:25 PM 6/5/2001 -0700, ja...@la... wrote:
> >Great - and you are absolutely right about the two camps for
> >implementation. In my work I took the 2nd strategy initially and ended up
> >going back and redoing that code to use accessor methods anyway.
> >
> >By using accessors at all times you are going to allow people like me to
> >override data type declarations with what I want but support Gunther's
> >wish for total simplicity of implementation.
> >
> >I do accept that there is a performance tradeoff.* Perhaps, before
getting
> >too excited about performan implications we might choose to benchmark
> >this. How you implement it will affect the performance. (ie/ using
> >AUTOLOAD could be done slow - but creating closures can make it fast.)
> >Also - by itemizing the list of possible keys upfront can you not open to
> >the possiblity of a pseudohash which is faster and more compact that
> >standard hashes?
> >
> >Jay
> >
> >* I remember Stephen's statement of flexibility over performance!
> >
> >On Tue, 05 June 2001, Stephen Adkins wrote:
> >
> > >
> > > Hi,
> > >
> > > Yes, we absolutely need accessors.
> > > I recommend an AUTOLOAD method implemented on Widget::Base to
> > > create accessors automatically (for now, anyway).
> > >
> > > However, there are two schools of thought on use of accessors vs.
> > > accessing the attributes directly.
> > >
> > >  1. use accessors everywhere, even inside the class
> > >  2. use accessors outside the class, access the attribute directly
> > >     from within the class
> > >
> > > I prefer #2 for performance.
> > > Some people argue #1 so that subclasses are resilient to change in the
> > > superclass.  I think we just don't have a complex enough code base to
> > > make #1 critical.  It won't be look before we finalize how to access
> > > attributes internally.  Then it should be stable.
> > >
> > > Stephen
> > >
> > > At 10:22 AM 6/5/2001 -0400, Jay Lawrence wrote:
> > > >Hey all,
> > > >
> > > >I was looking at the code and noticed one thing that will severely
> > limit our
> > > >implementation flexibility. It has to do with how properties are
> > accessed in
> > > >a non-abstracted fashion.
> > > >
> > > >When an widget is created (Widget::Base::new) you pass your
properties
> > which
> > > >then get stuffed in the object hash for later use.
> > > >
> > > >OK - so you're storing properties like $widget->{'name'} = "button1".
(Oh,
> > > >BTW, shouldn't you enclose hash keys in quotes? I know it generally
works
> > > >but it generates warnings).
> > > >
> > > >And you're obtaining it same way ie:
> > > >    print "My name is ".$self->{'name'};
> > > >
> > > >However, if you choose to have a different storage mechanism OR want
> > to get
> > > >fancy with how properties are resolved you need to use accessor
> > methods. ie/
> > > >    print "My name is ".$self->name;
> > > >
> > > >This way you hide the implementation of the widget (abstraction) from
the
> > > >calling routine. You actually need to use this strategy everywhere.
> > > >
> > > >There are a number of ways to handle this:
> > > >    AUTOLOAD - resolve name of method to a property or raise error
> > > >    manual accessor contruction - lots 'n lots of subs
> > > >    automated accessor construction - 1/2 doz packages in CPAN that
do the
> > > >job
> > > >
> > > >I know there will be arguments of efficiency vs. flexibility but I do
> > recall
> > > >Stephen saying that at this stage we'll be thinking more on
> > flexibility than
> > > >efficiency. But down the road we might be able to trade the expense
of a
> > > >function call with a more efficient storage mechanism like
pseudohashs.
> > > >
> > > >Jay
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >Perl-widget-developer mailing list
> > > >Per...@li...
> > > >http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
> > > >
> >
> >
> >
> >_______________________________________________
> >Perl-widget-developer mailing list
> >Per...@li...
> >http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
>
> __________________________________________________
> Gunther Birznieks (gun...@eX...)
> eXtropia - The Open Web Technology Company
> http://www.eXtropia.com/
>
>
> _______________________________________________
> Perl-widget-developer mailing list
> Per...@li...
> http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
>