On Nov 27, 2008, at 12:40 AM, Norman Palardy wrote:
To the consumer of that class there's no difference between the
method pair and a property (which I've always really liked in RB)
Depends on how you define consumer. I define it as the coder who is
using the class as a building block not only for the app as a whole
but also for subclasses... Methods can be overridden , properties can
not. HUGE difference. So there are significant different to the
"consumer" for me. You can not be TOTALLY blind to implementation
details when using intrinsic and 3rd party classes without
introducing to hard to find bugs.
AND it allows implementors the flexibility to implement that
"property" however is appropriate for that implementation.
That's entirely the point of an interface - tie every implementor
to an API NOT the specifics of how to implement it.
And that would be fine IF we wrote all the classes (and methods) we
used we wrote ... But We don't define the framework classes or 3rd
party plug-in or encrypted classes... That is why I called the view
you hold as an ideological one and not a practical one. In the
abstract you have a point... In the real world it just makes things
more difficult for us then they need to be.
BTW on a more mundane level, I find computed properties to be
superior to getter setter pairs (unless i need to override them)
because they help organize the class contents better. A long list of
methods are hard to read. Using computed properties mean only one
entry in the list (if the widget is closed). Also having all
properties (pseudo or not) group is a other logical tool I find
helpful for self documentation and "re-learning" classes i wrote a
while back.
Anyway being able to define properties as part of the interface
contract would make our lives a bit easier and I still don't see the
PRACTICAL (from a language perspective) downside... Why it would be a
bad thing,
I realize it might be a lot work under the hood ... but that is a
different issue than it's desirability. There is a reason it keeps
coming up year after year on the list!
- karen
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|