Hi,
> On 8 Feb 2015, at 23:22, Rowan Collins <rowan.coll...@gmail.com> wrote:
>
> On 08/02/2015 19:44, Andrea Faulds wrote:
>> Hi,
>>
>> I’m posting this in a new thread since people might (reasonably) be ignoring
>> further responses to the [VOTE] thread.
>
> Incidentally, you still used "reply" to create this message, so mail readers
> which base threads on headers (e.g. Thunderbird) rather than subject lines
> (e.g. GMail) still see it as part of the same thread (though the subject line
> change makes it stand out, so I spotted it anyway).
Oh yeah, my bad. :/
>
>> I’m considering a small change to the Scalar Type Hints RFC, specifically
>> about syntax. Quite a few people have said they don’t like the declare()
>> syntax, and it’s easy to see why. It’s rather verbose, it has all the quirks
>> of declare() (such as block syntax, not respecting scope), and it’s rather
>> ugly.
>>
>> Instead, I’m wondering if the following might be better:
>>
>> <?php strict
>>
>> Which would be used like so:
>>
>> <?php strict
>>
>> function foobar(): int {
>> return 1.0; // error!
>> }
>>
>> It’d be a per-file directive, so there’d be zero mixing of modes within one
>> file, and you’d avoid the quirks of declare().
>
> I find this much, much uglier than declare().
>
> Firstly, it seems to be creating a whole new syntax convention, which will
> need its own rules - Can it be preceded by a newline or other whitespace?
> Must it be followed by a newline (unlike a normal "<?php" opening)? Could you
> enable strict typing in a short tag using "<?= strict some_function($bar);
> ?>”?
<?php strict is allowed
<?php
strict
is not.
It would not be supported for <?=. It would be supported for <?. I guess it
would have to be followed by a new line.
> 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.
> 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.
> If you make the first "<?php" in a file special, that's still something that
> was never a consideration before.
This is technically correct, but only if that first block is empty. The
following is an error:
<?php ?>
Test
<?php namespace foo;
Though this isn’t:
<?php ?>
<?php namespace foo;
> 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.
> 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.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
