Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82205
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.182 as permitted sender)
Message-ID: <54D80302.8070206@gmail.com>
Date: Mon, 09 Feb 2015 00:44:50 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <8703B53E-2C4A-4AC6-95C4-D4F19C6D5221@ajf.me> <CE494877-8C5A-4315-BBF6-089FBD83F148@ajf.me> <54D7EF9D.7040700@gmail.com> <5E3D1500-E55D-4FEB-978B-FCA4AE4A1F13@ajf.me>
In-Reply-To: <5E3D1500-E55D-4FEB-978B-FCA4AE4A1F13@ajf.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Syntactical change to Scalar Type Hints RFC
From: rowan.collins@gmail.com (Rowan Collins)

On 09/02/2015 00:05, Andrea Faulds wrote:
>> Secondly, it is less specific than the current proposal - it suggests that PHP has a generic "strict mode", rather than a "strict type-checking" mode.
> It could be renamed to strict_types, but that loses some elegant.
>
>> Would more "strict" features be added to this mode later?
> No.
>
>> Or would other keywords be added so that you could, ahem, "declare" several directives at the top of your block?
> No.

I think this is all rather optimistic - if you use a specific term like 
"strict_types", people will want to use this syntax for other keywords; 
if you use something as general as "strict", they will want to add 
additional semantics to the existing keyword.


>> Thirdly, it has all the same scoping issues as declare() - you can break a function up into multiple <?php ... ?> blocks, so it's still possible to switch it halfway through a declaration,
> I’ve already sent an email in this thread about possible approaches to handling multiple blocks. My preferred solution would not allow what you describe, and instead behave like namespaces (must be in first block, affects entire file).
>
>> If this magic token has the extra effect of causing ?> to be ignored, that's a fairly major and unrelated feature, which would probably need its own RFC.
> ?> isn’t ignored - PHP blocks aren’t, and never have, been considered the same as separate files.

This was in response to your suggestion in the other message that that 
was a possible (though not your preferred) way to deal with the scoping 
issue. I edited my post for brevity, and didn't make the reference clear.

>
>> It's not like non-block namespace declarations having to be at the top of the file, because that is still a separate statement, it just has to be the *first* statement; whereas this appears to be designed to merge with the non-statement opening tag.
> Is there really an important difference between first statement, and first opening tag? The main difference in behaviour is empty blocks.

I guess it's more that statements, wherever they appear, are a 
recognisable part of the language. Tokens sharing a line with the 
opening tag aren't, and I don't see why this feature is so special that 
it requires the creation of a whole new syntax feature.


>> If you're going to go that far, why not just disallow the block-level syntax of declare() for this case, if that is the complaint? Or if the problem is the non-block syntax, why not enforce that a non-block declare(strict_types) be at the top of the file?
> Well, it’s not just that which is the problem: declare() is rather verbose and ugly. Also, having it behave differently from all other declare() statements would bring into question why we even bother reusing the declare() syntax.

I'd rather verbose and clear than concise and vague.

Regards,

-- 
Rowan Collins
[IMSoP]