On Wed, Apr 30, 2008 at 12:01 AM, Robert Cummings <[EMAIL PROTECTED]>
wrote:
>
> On Wed, 2008-04-30 at 01:22 -0400, Nathan Nobbe wrote:
> > On Wed, Apr 30, 2008 at 1:07 AM, Robert Cummings <[EMAIL PROTECTED]>
> wrote:
>
>
> > 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'.
>
> Seriously, are you having this much difficulty understanding that a
> property is not itself data until such time as it is given a value? If I
> say something has colour I haven't said what colour, only that it has
> colour. Red, blue, green, these are data. "colour" is a property. If I
> had an interface where I defined the following:
>
> <?php
>
> Interface Fibre
> {
> public $colour;
> }
>
> ?>
>
> I'm saying that all classes that implement Fibre must have a $colour
> property. i didn't say what colour.
>
> <?php
>
> Class Hair implements Fibre
> {
> public $colour = null;
> }
>
> $hair = new Hair();
> $hair->colour = 'brown';
>
> ?>
>
> The above is a much less wordy way of doing the following:
>
> <?php
>
> Interface Fibre
> {
> public function setColour( $colour );
>
> public function getColour();
> }
>
> Class Hair implements Fibre
> {
> public $colour = null;
>
> public function setColour( $colour )
> {
> $this->colour = $colour;
> }
>
> public function getColour()
> {
> return $this->colour;
> }
> }
>
> $hair = new Hair();
> $hair->setColour( 'brown' );
>
> ?>
>
> Now do you see the equivalence? I don't think I can simplify it anymore.
> Since they are equivalent your argument is void since it hinges on data.
> To throw your void argument back at you about a "property can be any
> type" so too can a parameter:
>
> $hair->setColour( 3.14 );
>
> This is a feature of a dynamic language, not a flaw in my argument. And
> to beat the dead horse... a parameter declaration isn't data either.
so really, all we would get is a group of member variables we know would be
there... wow, that seems pretty pointless to me. and in the case of the
setter, the client doesnt know about the logic behind the call, so the fact
is supplying 3.14 may not result in 3.14 actually getting set. this is why
setter methods are import, per my previous statements. i do not consider
adding data 'after declaring properties' in interfaces equivalent to
supplying an implementation for the method, because php is not strongly
typed, therefore no class will ever be able to control what sort of data is
set on the properties. that is the entire problem with your proposition.
i have to work today, and im sure people are getting sick of my bickering,
but truthfully, i would like to know why interfaces were added to php in the
first place? where, if any place, did they take inspiration from, java,
c++, neither ? i only ask because im dying to know and we're on the topic..
-nathan
