> Regarding immutability, Richard says "PBV objects should be immutable so that they
> are not confused with remote references, which present a mutable interface. Because
> a PBV object is a copy, changes to its state would not be reflected on the server.
> Making PBV objects immutable avoids confusion."
>
> I don't buy it. I always have to know when I'm dealing with a copy or the original,
> regardless of whether the instance presents setters. It doesn't confuse me or any of
> the programmers I work with, so why should I restrict myself this way?
I have to agree with this statement.
I tend to use naming conventions to tell me anything special about
a class, such as indicating a PBV object. I would never bother to check
for setters to determine if an object was PBV or not. Further, I don't
see why a PBV that involves my portfolio can't have some setters that
allow me to control calculations, or why I can't adjust the values that
were returned to perform "what if" analysis.
tim.
Tim Endres - [EMAIL PROTECTED]
ICE Engineering, Inc. - http://www.ice.com/
"USENET - a slow moving self parody." - Peter Honeyman
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
