Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62182
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 64.22.89.133 as permitted sender)
Date: Wed, 15 Aug 2012 11:40:17 +0100 (BST)
Reply-To: Andrew Faulds <ajf@ajf.me>
To: Stas Malyshev <smalyshev@sugarcrm.com>, 
	Anthony Ferrara <ircmaxell@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <2002740165.15194.1345027217247.JavaMail.open-xchange@oxwebmail.registrar-servers.com>
In-Reply-To: <502AADEB.2020102@sugarcrm.com>
References: <CAAyV7nEZdNbWht+8Fy4ZpS=AjkzYq4Yk7XhJWV3sSV_NpgVS2g@mail.gmail.com> <502A81AD.1070303@ralphschindler.com> <CAAyV7nFMONBrp-zBW1gvjsrTZMVvn-TNZtNUwa5g=aEttfpsWQ@mail.gmail.com> <502AA750.1060406@ralphschindler.com> <502AADEB.2020102@sugarcrm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Importance: Medium
Subject: Re: [PHP-DEV] Decorators Revisited
From: ajf@ajf.me (Andrew Faulds)




On 14 August 2012 at 20:58 Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> Hi!
>
> > Simply because your object responds to all the same methods of, for
> > example, the FooInterface, does not make it a FooInterface subtype.  It
> > just means that in the "duck typing" sense of the phrase, it can act
> > like a FooInterface for people that are not necessarily concerned that
> > it's actually not is_a() FooInterface.
>
> Excellent point here. I have a feeling that with these proposals people
> want to eat a cake and have it too. To have strictly defined typing
> structure enforced by strict parameter checks, instanceof checks, etc.
> and at the same time have the freedom of duck typing. I don't think it's
> going to work well - if you want duck typing, that's one thing, if you
> want class hierarchy, that's another thing. Both are viable models for
> different cases, but I don't see how they can work using the same
> operators and language constructs. They should be distinct.
>

This is something which bothers me about PHP as it is at the moment. PHP seems
to me like it should be a dynamic language, and it is quite dynamic: no static
typing, has weak typing, you can add instance members at runtime, etc.

However, there has been a trend for adding more... non-dynamic (?) features to
the language. Interfaces for example. Yet you can also duck-type things. I think
PHP risks becoming very unclear as to what the "right" way to do things is. It
must be confusing to write code that has to deal with both duck-typing and
interfaces. I just think perhaps PHP should decide if it's supposed to be
dynamic or non-dynamic, because just now it looks like a confusing mix of both.
(although I guess duck-typing can be used for interfaces, just not really the
other way round, i.e. if you expect an object of an interface you can't just
pass one implementing the required methods)

Or, if it is going to support both models, it should at least have first-class
support for both. Being able to dynamically modify classes, for instance.

> Now, we could probably make duck typing a bit easier by allowing to
> check if specific object can respond to specific interface. But I'm not
> sure if it's worth the effort - why not just have it implement the
> interface then? In any case, I think duck typing improvement may be a
> good place for proposals, but let's not confuse it with inheritance
> hierarchy.

What if asking for an interface just checked to see if a class implemented the
required types, and "implements" didn't make the class have that interface, but
just made the compiler error if it didn't implement everything required.

> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Andrew Faulds
http://ajf.me/