Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95173 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22812 invoked from network); 15 Aug 2016 07:47:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Aug 2016 07:47:21 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.230 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.230 mail4-3.serversure.net Linux 2.6 Received: from [217.147.176.230] ([217.147.176.230:46303] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E7/9C-36656-68371B75 for ; Mon, 15 Aug 2016 03:47:19 -0400 Received: (qmail 10431 invoked by uid 89); 15 Aug 2016 07:47:15 -0000 Received: by simscan 1.3.1 ppid: 10425, pid: 10428, t: 0.0811s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 15 Aug 2016 07:47:15 -0000 To: internals@lists.php.net References: <11f9c899-77b4-da50-f0f7-dc2d16b1829c@gmail.com> <431d5b9c-15ef-9af8-7a55-b776b2dd22ad@gmail.com> <5d38c41d-f189-56d2-be58-d60be3fd1bd9@gmail.com> Message-ID: <0511b290-62eb-602c-f656-65540c721903@lsces.co.uk> Date: Mon, 15 Aug 2016 08:47:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Namespaces internal refactoring From: lester@lsces.co.uk (Lester Caine) On 15/08/16 01:42, guilhermeblanco@gmail.com wrote: >>> Annotation parser needs to understand what was "use"d, so it can >>> > > properly refer to FQCN. That way, we need to somehow discover something >> > >> > I see what you mean. This seems to be a problem because you are trying >> > to do compiler things without the support of the compiler. I'd say the >> > right solution is to let the compiler do these things... >> > > Yes, yes and yes. When can we get that? > I'll again reinforce that library developers have to come up with creative > ways to handle lack of support in the language. That was just one example. > Instead, the language should offer proper support and let library > developers to come up with creative tools (and now creative ways) to > improve and ease end user's development. In the past it used to be easier to write extensions and the way I still see it is that anything that you don't want the 'customers' to play with should be packaged that way. It's the 'creative ways' of using the USER interface which is the problem and as soon as you come up with some bondage SOMEONE will work out how to bypass it! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk