Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50669
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        b=t2Ajr+SDcsynbpsCnakyDscnda8fpWk9bprB3V90VmjONICYqFpbSLdoZ4Xq5BtEey
         WaiEi1LmBCqKvrMzPRy//ja92DvKQldfDFw4Bz5WhqTIl21mwjdHC3Mw1H/l06C7yrqi
         pyz+tmXxzqAThlWsucV0xw/ZecusAU2QKic8I=
MIME-Version: 1.0
Sender: dallasg@gmail.com
In-Reply-To: <4CF28CFC.2060204@gmail.com>
References: <1290879624.7033.826.camel@guybrush>
	<AANLkTinp+QsgqM7rRUcC-RmrMYbgxQHc+DBiPUUxvq_y@mail.gmail.com>
	<op.vmvy9m0kidpuyk@cataphract>
	<4CF27AAC.9010704@divbyzero.net>
	<AANLkTikngNK=OaQEjW4TLna8jUhYitdQQW3aJPLEg9AC@mail.gmail.com>
	<4CF28CFC.2060204@gmail.com>
Date: Sun, 28 Nov 2010 12:24:02 -0500
Message-ID: <AANLkTim3OeYZ4NFj4t=bCoitmgQYoCEh6mSs30hWQUp2@mail.gmail.com>
To: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= <keisial@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016368325acca933f049620385c
Subject: Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
From: dallas@gutauckis.com (Dallas Gutauckis)

--0016368325acca933f049620385c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2010/11/28 =C1ngel Gonz=E1lez <keisial@gmail.com>

> Dallas Gutauckis wrote:
> > Just to be clear, this works on the assumption that we don't know the
> class
> > name that the function resides in?
> >
> > I understand the search argument, but to me it only applies to function=
s,
> > not methods. Is anyone arguing for removing the T_FUNCTION requirement =
on
> > functions?
>
> Even knowing the class you are calling, and assuming the common
> convention of
> one file per class, you may not know in which file is it implemented.
> It's annoying
> to go into the class, find out it's not there, grep the parent class,
> and having to
> repeat the process three or four levels up.
> Whereas with a unique enough name, grepping the functions get all the
> possible
> implementations.
>
> Plus, it's not always easy to know in which class to look something :-)
>
>
I understand the concern from above, but I don't agree with it
fundamentally. The kind of practice suggested by this search mechanic tells
me that either there is lack of or little documentation, and lack of or
little understanding of the codebase in which the code resides thereby
making this argument flawed based solely on the assumption that the majorit=
y
of code is (or should be) poorly maintained/documented.

Below is simply bad programming practice in many ways. No validation of typ=
e
(neither through type-hinting nor an instanceof check) is done, which is wh=
y
the code is so difficult to trace back. Presumably, you'd also have some
form of documentation (PHPDoc, anyone?) that would facilitate the search fo=
r
the declaration of that function. Again, that assumes a better programming
practice than is being provided as the example below. One would hope that
someone excluding their function keyword would also be "up to date" enough
to be validating objects.


> function baz( $param ) {
>    $param->morlocks();
> }
>
>

--0016368325acca933f049620385c--