perl-widget-developer

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

[<ja...@la...>]

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

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

[Gunther B. <gu...@ex...>]

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/

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

[Jay L. <Ja...@La...>]

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
>

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