Re: Class Properties in Interfaces?

On Wed, Apr 30, 2008 at 1:07 AM, Robert Cummings <robert@interjinn.com> wrote: > > On Wed, 2008-04-30 at 00:27 -0400, Nathan Nobbe wrote: > > On Wed, Apr 30, 2008 at 12:05 AM, Robert Cummings > > > > Abstract classes and interfaces are not the same. They are > > used for > > fundamentally different reasons. An interface is to enforce a > > contract > > for all implementations of the interface. Therefore if I were > > to create > > an interface with an interface property of x, then all > > implementations > > using that interface would know that property x exists and > > could use it > > thusly without having to check for it's existence. > > > > i am fully aware of the differences between interfaces and abstract > > classes. however, if a public method is defined on any class, > > abstract or concrete, it may be used without checking by client code; > > i believe thats the entire point.. > > > > Using an abstractclass is a hack, it's not sufficient for > > enforcement, and you can't > > combine multiple abstract classes as you can with interfaces. > > > > abstract classes have their place. primarily they are well suited for > > template method because some methods can be forced to be implemented > > by children and others can be optionally overridden. > > > > and lastly, coming to multiple inheritance (for lack of better > > terminology); that is the only argument with any value for adding > > public attributes to the interface construct; however i am still not > > receptive to it. from my perspective data is an implementation > > detail, period. > > We are not talking about data here. We are talking about properties. > Data is assigned to a property which is akin to functionality being > assigned to a method. A property has all the features of the most simple > getter/setter method combination in one fell statement and without the > envelope overhead. As such, there is no reason why it could not be part > of the interface design. so a 'property' could be any data type? that sounds contradictory to the concept of an interface to me. the only special connotation i have ever encountered for the term 'property' is my *very* brief work w/ vb.net as a teacher. there is a mechanism whereby getters and setters can be declared and a member variable can be named.. then when using instances of the class, client code uses the name of the 'property' which has the same syntax as accessing a public data member, however, the client is transparently being driven through the methods of the 'property'. between SPL ArrayAccess, and magic methods, php already has multiple ways to realize 'properties'. -nathan