Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66704
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAEi=BNqvzETejStaAuJMP79gu5EG2vRhCaqPLtp10Dy-bb0Mw@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>
 <CAAEi=BNqvzETejStaAuJMP79gu5EG2vRhCaqPLtp10Dy-bb0Mw@mail.gmail.com>
Date: Tue, 19 Mar 2013 17:35:55 +0100
Message-ID: <CACv1KMhRhEgCvKuE3k1HfDpE1X191xAVDFwKph7ySzn7qim7bw@mail.gmail.com>
To: PHP Development <internals@lists.php.net>
Cc: Pierre du Plessis <pierre@pcservice.co.za>, Bruno CHALOPIN <bruno@chalopin.fr>, 
	=?UTF-8?Q?Mat=C4=ABss_Roberts_Treinis?= <mrtreinis@gmail.com>
Content-Type: multipart/alternative; boundary=089e0122ed7489e65904d849b50c
Subject: Re: [PHP-DEV] __invokeStatic() method
From: dnl.rlnd@gmail.com (Daniele Orlando)

--089e0122ed7489e65904d849b50c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

It is clear to me that there are valid reasons to say yes to this proposal,
but there are a lot to say no too.
Even if it could be interesting in theory, due to of how PHP handles
collisions between classes and functions names (no check at all),
implementing a callable class could break existing code.

At the moment a class and a function with the same name can coexist,
but implementing a callable class would mess this state of affairs.
With the adoption of the namespaces, I think that this collisions could
became
so rare to not exist, but of course we cannot ignore pre existing
situations.

As suggested by Patrick Schaaf, a workaround is to implement a function,
with
the same name of the class, that behaves like a wrapper for a method call.
It is a good point, but has the negative side that it must be implemented
for every
class who follow this pattern. It is not usable in a framework for example.

It seams that to handle consistently a callable class is to modify PHP
to treat functions/classes names case sensitive and to trigger an
E_WARNING (or similar) in case of collision.
In this way new code could take advantage of the new syntax and old code
could simply suppress the warning.

What do you think?

2013/3/19 Mat=C4=ABss Roberts Treinis <mrtreinis@gmail.com>

> Bruno,
>
> Poor or questionable design or language use is not what this discussion i=
s
> about. PHP's greatest strength is its flexibility - PHP does allow to do
> silly and sometimes, questionable things. Trying to limit this flexibilit=
y
> 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 ha=
ve
> seen such code myself in some applications where methods are shorthand's =
to
> specific functionality provided as the class with same name. I even appro=
ve
> such use and believe it can be quite handy for utility functions which do=
es
> 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 withou=
t
> a real profit to the language or its users. By my opinion, syntax
> considering function and object calls should stay separated to ensure cle=
an
> 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
> with
> > > > 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 functio=
n,
> > or
> > > > invoke the __invokeStatic method if it is available?
> > >
> > > It will clearly technically lead to a problem. Now I don't see why in
> the
> > > world a class and a function could share the same name. Regarding
> > > conventions, a class name should begin with an uppercase character an=
d
> a
> > > function a lowercase one. I don't see any relevant use case where a
> class
> > > 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().
> >
>

--089e0122ed7489e65904d849b50c--