On Wed, Apr 30, 2008 at 1:07 AM, Robert Cummings <[EMAIL PROTECTED]>
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

Reply via email to