On 27-Nov-08, at 7:48 AM, Karen wrote:
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.
You explanation is precisely why you DONT want to use an interface to
tie every subclass to a particular implementation that may be ill
suited to it's functioning
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.
It's a practical one based on 6 years of writing Java code in a very
large industrial setting where interfaces were extensively used and
10+ years of RB coding.
The fact that the frameworks don't use interfaces for everything has
no real bearing on why interfaces are the way they are or should be
the way they are.
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.
A computer property is simply a getter setter pair presented differently
Save it as VCP and have a look
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,
It's not how you design by contract which is the primary design
philosophy that interfaces support
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!
It's not desirable hence why it keeps getting the same response (Mars
objected, Aaron objected and I do as well)
If you want to force implementations to have a particular property use
a class and subclass it.
If you want you classes to adhere to an API use an interface.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|