Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65610
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.173 as permitted sender)
References: <5FC22A05-FE01-4222-892C-773ECC39E471@gmail.com> <510F529F.9080405@garfieldtech.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <510F529F.9080405@garfieldtech.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID: <4A9DDC77-3975-4F47-B3EC-E740B8C9FBF2@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Date: Mon, 4 Feb 2013 18:44:22 +1100
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Questioning the future of PHP
From: davidkmuir@gmail.com (David Muir)

We still don't have a way to auto load non class entities. Other than that, P=
SR-0 does solve the majority of autoload use cases.

Cheers,=20
David

Sent from my iPhone

On 04/02/2013, at 5:18 PM, Larry Garfield <larry@garfieldtech.com> wrote:

> On 02/03/2013 08:51 PM, Matt Wilson wrote:
>> Hello all. I'd like to start by saying that I am by no means an expert on=
 the subject at hand, and my knowledge is limited to pretty much basic C/C++=
. I have done little more than patch and write ad hoc extensions for PHP in t=
he past. I'm not looking to criticize so much, as I'm just interested in an h=
onest discussion, for my own sake and understanding.
>>=20
>> Many years ago I was on this internals list lamenting that PHP lacked nam=
espaces. I was passionate in my conviction that it couldn't be a true langua=
ge if it lacked them. But it wasn't until they were finally being considered=
 that I realized the one weakness in PHP that prevented a proper namespace s=
ystem. The autoload problem. Since PHP lacks an inherent style of code impor=
tation, it is a decision largely left up to the developer. This of course ca=
uses an order of precedence problem.
>>=20
>> Now, I won't lie, some of my beef with namespaces as they stand is the \.=
 What can I say, I like a certain feng shui in my code. I understand the tec=
hnical limitations (or at least think I do) and the problem of ambiguity wit=
h other operators, however I feel more effort might have been made.
>>=20
>> If I were to pull some examples out of my ass, and feel free to rebuke me=
 if I'm missing something obvious,
>>=20
>> [namespace foo.bar]
>>=20
>> new [foo.bar.SomeClass]()
>>=20
>> Would that be so hard to distinguish in the parser? If it is, I'd be grat=
eful to know why.
>=20
> Maybe it would work, maybe it wouldn't, I don't know.  But that ship saile=
d a long time ago and it cannot be changed now without breaking a few millio=
n lines of code.  Please let that issue die.
>=20
>> Touching back on what I mentioned earlier about PHP not having an inheren=
t way to load files, and in daily use it's somewhat arbitrary. I share the p=
hilosophy that the programmer should tell the code what to do, and not the o=
ther way around; however, I think some enforced structure can be good. This i=
s something of a wet dream of mine and one I highly doubt will come true, bu=
t to get rid of __autoload (or at least supplant it with a default loader) w=
ould be a dream. I think it's something that PHP needs, to complete some one=
 of advances its made in recent years.
>>=20
>> Thanks,
>> Matt
>=20
> "The autoload problem" has already been solved by PSR-0.  If you're not us=
ing it yet, you should.  All the cool kids are.
>=20
> http://www.php-fig.org/
>=20
> If you're using Composer to manage dependencies, it includes a fully capab=
le PSR-0 autoloader that "just works", as well as a classmap-based option.  I=
f you're not using it yet, you should.  All the cool kids are.
>=20
> http://getcomposer.org/
>=20
> --Larry Garfield
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20