Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50700
Return-Path: <dmgx.michael@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 68337 invoked from network); 29 Nov 2010 17:41:40 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 29 Nov 2010 17:41:40 -0000
Authentication-Results: pb1.pair.com smtp.mail=dmgx.michael@gmail.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=dmgx.michael@gmail.com; sender-id=pass; domainkeys=bad
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
DomainKey-Status: bad
X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01
X-PHP-List-Original-Sender: dmgx.michael@gmail.com
X-Host-Fingerprint: 74.125.82.54 mail-ww0-f54.google.com  
Received: from [74.125.82.54] ([74.125.82.54:60829] helo=mail-ww0-f54.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 34/F3-42097-3D5E3FC4 for <internals@lists.php.net>; Mon, 29 Nov 2010 12:41:39 -0500
Received: by wwb31 with SMTP id 31so3282530wwb.11
        for <internals@lists.php.net>; Mon, 29 Nov 2010 09:41:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:received:date:message-id
         :subject:from:to:content-type;
        bh=1yZ0pS//xlqwV8U5ZkvhYhDKnf7tA+Cp7wFKOirfknY=;
        b=qTAY8ESarOENANB3+/VPkp8tjnYwNFCHcXz1Hp6Wuh/Uw8MQ/XbEh3jvsF/A4Cek+Q
         jg5dNhOby89fwZMsPGOpEzR5GcOUZUQxxByH4wAfFxEqdmVFzcPAvuJuWeiLzQl97Nm7
         Ij39zLw4XwnAIi2YeyBDzha9aRc0TOTNGjTWw=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=QXLgSSseI/6zmeMyjbG3NVxnry8zYlDkqBHKZcOibo1yVyJ2MAvH9pC3CYXq0g4ma+
         8PCLTbcYkqqCc3LFT+cT4infgVr2qzT6DfmCEvVcN9cw075hDKKdL7jV6sa+8Fxy0piU
         jcMFbw101kjWVRr/Lq7QNkdbDyGPfmE7IJ5XQ=
MIME-Version: 1.0
Received: by 10.216.143.163 with SMTP id l35mr5084973wej.68.1291052496263;
 Mon, 29 Nov 2010 09:41:36 -0800 (PST)
Received: by 10.216.8.9 with HTTP; Mon, 29 Nov 2010 09:41:36 -0800 (PST)
Date: Mon, 29 Nov 2010 12:41:36 -0500
Message-ID: <AANLkTinX9hD2k_xiPa2e7XhKacFy6-B_uASoQgJLeW0J@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016e6d5895f6d1ae904963495db
Subject: Hello - been pointed this way for suggestions - Including.
From: dmgx.michael@gmail.com (Michael Morris)

--0016e6d5895f6d1ae904963495db
Content-Type: text/plain; charset=ISO-8859-1

Been pointed this way by some folks that this is the place to set
suggestions on changes to the functions or language. I have two at the
moment, and that is to the including functions (include, require,
include_once, require_once). They need to be considered separately as they
address two different problems.

Tag Selection at include.
First is the problem of short tags and they aren't being widely used because
of the problems they cause for XML files.

Why not allow the tag type to be chosen at file include? This should bypass
the objections seen in http://wiki.php.net/rfc/shortags

The parameter would be set by a constant.

Val  Constant           Effect
0    PHP_TAGS_INI       Use the ini setting. Default.
1    PHP_TAGS_STANDARD  Use standard PHP tags.
2    PHP_TAGS_SHORT     Use PHP short tags.
3    PHP_TAGS_NONE      No tags allowed in file, parse as PHP.
4    PHP_TAGS_SCRIPT    Script tags <script type="php"></script>
5    PHP_TAGS_ASP       ASP style tags <% %>

PHP_TAGS_NONE is suggested as a possible bonus mode this approach allows
that wouldn't be feasible otherwise.  In this mode the engine treats the
whole file as PHP and doesn't allow mode switching.  This might allow the
engine to parse the file faster.  Importantly it would allow framework
designers to enforce that certain files not have HTML in them - such as a
database class, or a custom child class.  Admittedly it doesn't stop
echo'ing the html, but it drives home the point to all but the densest that
perhaps this isn't the place to be printing/echoing.  It would encounter the
problem of current tools assuming that a PHP file will always have a
starting <?php tag.

The tag method selected affects the file being included only, so tag modes
that are undesirable in some circumstances - short tags - can be segregated
from those circumstance.


Namespace Defined At Include.
This addresses a separate problem from the above, but involves the same
functions - though it might be better to have another rather than a new
parameter on the include statements. The problem is that files always
include to the global namespace, then need to defined their namespace.  This
behavior is undesirable with PHP template files and putting a namespace tag
at their start is clumsy at best. Two solutions are proposed - they aren't
exclusive to each other.

Solution 1. Allow Namespace to be declared as file is included.
Hence

include('file.php', __NAMESPACE__);

Would include the code in file.php into the current namespace.  If file.php
declares a namespace, then that namespace becomes a sub namespace.

Solution 2. New function to set target namespace.

includeNamespace( __NAMESPACE__ ); // will set current namespace as the
default files include into.

Both could be adopted.

Ok, that's all.

--0016e6d5895f6d1ae904963495db--