Gavin Sinclair [mailto:gsinclair@soyabean.com.au]:
What if a class tags itself as a "hash type" but an instance of it
redefines a method in a way that contradicts that type?
I'm not being alarmist, but your messages have shown a great deal
of concern for knowing that an object does what it advertises. How
do you see the above scenario, then?
I don't think your idea is a bad one, by the way.
No, you're not being alarmist at all; even in statically typed
languages, this is possible.
I could define
class Foo < Doer
{
int does(int this) // reimplementation of Doer::does
{
// something with an undesired side-effect
}
}
-austin
···
--
austin ziegler * austin.ziegler@evault.com
That's my point about not tightly constraining the objects to their described
interfaces. Any programmer can come along and break anything if they want
to. In C++, Java...you can do it anywhere. It's a moot point to try and
force an object to do its job properly through language constructs. That's
what the programmers are there for.
Sean O'Dell
···
On Monday 07 June 2004 07:44, Austin Ziegler wrote:
Gavin Sinclair [mailto:gsinclair@soyabean.com.au]:
> What if a class tags itself as a "hash type" but an instance of it
> redefines a method in a way that contradicts that type?
>
> I'm not being alarmist, but your messages have shown a great deal
> of concern for knowing that an object does what it advertises. How
> do you see the above scenario, then?
>
> I don't think your idea is a bad one, by the way.
No, you're not being alarmist at all; even in statically typed
languages, this is possible.
I could define
class Foo < Doer
{
int does(int this) // reimplementation of Doer::does
{
// something with an undesired side-effect
}
}