Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66698
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAJbumGMfU5mj9ngPSSYNQC0sgMb5W8dOmJ40SygWz8YxCFSxRQ@mail.gmail.com>
References: <CACv1KMh_ahrK=bqsESzBq50KmfQxmZht-NR6Dc8acykMt1e06w@mail.gmail.com>
	<CAJbumGNP=fAcQABrxa_1P1m0KcazEXp731PfSc0kHi23673xKQ@mail.gmail.com>
	<CA+_UWzpccY6NQkwHpnfw7P37nfK003zwACj6LA1gA+=YSj-PyA@mail.gmail.com>
	<CAJbumGNs-yUBktBvvDOGRTcgteX_JsqQmspd+GQSOAo8KgvrAQ@mail.gmail.com>
	<CAAEi=BO8qVJNe_Yi0=9vSn7MgDjPi=cCU8K2241O420OQM9X4A@mail.gmail.com>
	<20.05.17382.B0318415@pb1.pair.com>
	<CAJbumGM6x4icDPpDfmR3dz1C9wkwrBsj8ouOgP9=HrRKGkcWBw@mail.gmail.com>
	<4F.50.28284.AA918415@pb1.pair.com>
	<CAJbumGMfU5mj9ngPSSYNQC0sgMb5W8dOmJ40SygWz8YxCFSxRQ@mail.gmail.com>
Date: Tue, 19 Mar 2013 10:37:02 +0200
Message-ID: <CAAEi=BNqvzETejStaAuJMP79gu5EG2vRhCaqPLtp10Dy-bb0Mw@mail.gmail.com>
To: Pierre du Plessis <pierre@pcservice.co.za>
Cc: Bruno CHALOPIN <bruno@chalopin.fr>, PHP Development <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0408930b76cfc204d84302d3
Subject: Re: [PHP-DEV] __invokeStatic() method
From: mrtreinis@gmail.com (=?UTF-8?Q?Mat=C4=ABss_Roberts_Treinis?=)

--f46d0408930b76cfc204d84302d3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bruno,

Poor or questionable design or language use is not what this discussion is
about. PHP's greatest strength is its flexibility - PHP does allow to do
silly and sometimes, questionable things. Trying to limit this flexibility
is like trying to limit PHP, which is obviously bad thing to do. Example
given by Pierre clearly shows possibility of such code, and in fact, I have
seen such code myself in some applications where methods are shorthand's to
specific functionality provided as the class with same name. I even approve
such use and believe it can be quite handy for utility functions which does
some specific task and where you do not want your function to be miles
long, so you split it to handful of methods and wrap them in class.

These proposed changes can potentially break a lot of peoples work without
a real profit to the language or its users. By my opinion, syntax
considering function and object calls should stay separated to ensure clean
and convenient way to properly identify one from another. Also, there are
no or never has been clear and unified standard by PHP for how to name
things in PHP. If one chooses to name his functions with names similar or
exactly like classes, he must be able to do so.

2013/3/19 Pierre du Plessis <pierre@pcservice.co.za>

> > Le Tue, 19 Mar 2013 09:37:43 +0200, Pierre du Plessis a =C3=A9crit :
> > > It would break existing software if you have a class and function wit=
h
> > > the same name.
> > > Consider the following example:
> > >
> > > class foo {
> > > }
> > >
> > > function foo()
> > > {
> > >
> > > }
> > >
> > > Now what if you have several calls to foo() in your existing
> > > application? With the new change, will those calls call the function,
> or
> > > invoke the __invokeStatic method if it is available?
> >
> > It will clearly technically lead to a problem. Now I don't see why in t=
he
> > world a class and a function could share the same name. Regarding
> > conventions, a class name should begin with an uppercase character and =
a
> > function a lowercase one. I don't see any relevant use case where a cla=
ss
> > and a function should share the same name.
> >
> >
> PHP doesn't care about uppercase or lowercase when it comes to function
> names.
> Have a look at http://3v4l.org/cePT5 for an example.
> And not everybody uses conventions anyway (although they should)
>
> Although it is not common to have a class and function have the same name=
,
> it can happen.
> Take the following code as an example.
>
> class Debug {
>     public static dump($var)
>     {
>         // some code to debug $var
>     }
> }
>
> function debug($var)
> {
>     return Debug::dump($var);
> }
>
> The problem is clear if you have a __invokeStatic method in the debug
> class, and you want to make a call to debug().
>

--f46d0408930b76cfc204d84302d3--