🚀 go-pugleaf

At a minimum you should make your code robust enough to take bogus
values and nulls from the user and either defang them or put your image
back.

I don't understand why "private" is crazy, though.  Data hiding and
limiting access is quite good.  I have plenty of beans with private
members, public getters but only package local setters.  That makes
things a little easier on my side and provides a good level of
protection and visibility for the client.

-Rich

dnoyeB wrote:
> 
> Well yea, when its my code.  But this is a bean, and the end user may get
> happy and start fiddling around with the innards of the object I pass back.
> Its crazy I know, but so is using "private."  Its an ImageIcon, he could
> easily replace the image itholds, or set its internal image to null.  My
> bean would not like that.  Thats why im considering the copy.  ImageIcon
> does not have a copy constructor though...
> 
> "John McGrath [TeamB]" <ng-b@JPMcGrath.net> wrote in message
> news:MPG.15a34d4ad4cde13a98a2e5@forums.borland.com...
> > On Tue, 26 Jun 2001 15:12:10 -0400, "dnoyeB" <lamont_gilbert @
> > rigidsoftware.com> wrote:
> >
> > > HOwever, I am concerned about passing the old object reference
> > > into this event to be handed around and molested/violated.  I
> > > would prefer to pass a copy of the object, but is this proper?
> >
> > I do not think you have to create a copy, but there is no reason that
> > it would not work.  Well behaved code should probably not be changing
> > the objects passed to it in a property change notification, so I do not
> > think it is really necessary in most cases.  Depending on how many such
> > events are generated, it could become a performance issue if you copy
> > the object.
> >
> > --
> > Regards,
> >
> > John McGrath [TeamB]
> >
> > ---------------------------------------------------
> > Before sending me e-mail, please read:
> >     http://www.JPMcGrath.net/newsgroups/e-mail.html