You're right, there is no formal definition of an object, and there is no single form of object orientation. However, the requirement that an object combine state and behavior is sufficiently general as to be acceptable to nearly everyone, from Smalltalk programmers who would want to talk about behavior as message passing, to C programmers who write functions that take struct pointers as initial arguments.
The reason languages do not allow inheritance of state without behavior is that it runs counter to the goal of encapsulation. Whether you're doing straight function coding or working on a deep OO tree, encapsulation is basically always a good idea. To take the guts out of a subroutine or object and toss away the abstraction layer provided by the interface is to take a step in the opposite direction of ease of development, maintainance, sanity :)
A better way to get at the separation of state from (certain) behavior is to look at something like the classic model-view-controller pattern, where you've got all your state wrapped up in one class, methods for manipulating the state in your controller class, and a presentation layer in the view class. Thus you've got separation and encapsulation, and you haven't introduced this new burden of manually coordinating state and behavior which in the vast majority of cases the programmer is not going to need or want.
In reply to Re: Re: Re: Re: Re: Re: Class::Interface -- isa() Considered Harmful
by djantzen
in thread Class::Interface -- isa() Considered Harmful
by chromatic
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |