On Nov 27, 2008, at 9:48 AM, Karen wrote:
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!
Now, in the 60 seconds I've reconsidered this thread, I'm thinking
that this is not really a matter of changing Interfaces, but allowing
for Multiple Inheritance (*opens can of worms*). Of course, I've been
wrong before.
Michael
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|