At 0:01 +0200 2000_12_17, Brennan Young wrote:
>This 'Getters' and 'setters' debate comes up pretty regularly.
Yes, we need to end it once and for all, by making a decree, with
proper guidelines to which any Lingo-coder must adhere or be banished
from participating in public discussion on the estimated lists.
Then the black sheep can start secret underground organizations where
they stand together against the evil deeds done to them. After seven
years of suffering the issue breaks through to mass-media attention
and evil OOP-empire is torn to pieces by CNN and the world press,
fighters for justice.
Hollywood makes a film starring Jane Fonda and Sylvester Stallone,
which depicts the unfair treatmeant of the non-OOP community so
emotionally touching, that everybody who sees the movie, say how
deeply they could relate to the feeling of being oppressed by strong
and dark forces. The light breaks through and the free and creative
spirit of happiness prevails again.
>I'm prepared to fly the OOP flag from time to time, but I've always felt
>a little uncomfortable with this idea of having a 'getter' and 'setter'
>for each 'public' property.
Well, son do you have public properties?
>I've never been able to come up with really good reasons why a generic
>'getter' and a generic 'setter' for all properties aren't just as clean.
>(Jakob mentioned some good ones about scope during debugging, but
>they're not *that* good).
Just want to clarify, that I made arguments as to why you should
always access an object by methods and not by properties. I did not
make any argument why it is better to have specific methods rather
than generic accessors. I did say that I myself ususally use specific
methods, and that I think that is stylistically superior, but that is
not an argument, its just personal preference. And I think that
preference resonates quite well with your concept of "services".
> > 1.All data is private. Period.
> > (This rule applies to all implementation details, not just the data.)
Fine.
> 2.get and set functions are evil.
> > (They're just elaborate ways to make the data public.)
Hmm...
> > 3.Never ask an object for the information you need to do something;
> > rather, ask the object that has the information to
> > do the work for you.
Bullocks. This guy must be living in a dreamworld.
If I have a baddie hunting the goodie, then the baddie asks the
goodie about its data such as position and direction, and then the
baddie himselfs takes appropriate action. It's not like the baddie
then asks the goodie to help the baddie catch him.
> > 4.It must be possible to make any change to the way an object
> > is implemented, no matter how significant that change may be,
> > by modifying the single class that defines that object.
Unless you reach the point where you realize that you need to change
the interface of a class. These things do happen in a flexible
development, but obviously it is what you strive to prevent from
happening.
> >5.All objects must provide their own UI.
I don't understand.
Jakob
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
