Re: [PHP-DEV] [RFC][Discuss] Increase non-syntax runtime-impacting RFC voting threshold to 60%

2017-09-13 Thread Nikita Popov 
On Thu, Sep 14, 2017 at 4:42 AM, Sara Golemon  wrote:

> https://wiki.php.net/rfc/rfc.voting-threshold
>
> This topic has come up on the mailing list a few times, so I'd like to
> formally open the topic for discussion.
>
> I'm generally pretty liberal when it comes to allowing the PHP
> language to evolve and explore its identity, but the truth is a
> feature that has 30 people vote against it and 31 people vote in favor
> of it is not a mandate by any stretch of the imagination.  It's an
> opportunity to examine why a divide exists and if we're all being
> honest with each other, improve the original idea before it becomes a
> maintenance burden.
>
> Please note the "Open Question".  I'm not all that sure 60% is enough
> of a mandate either, but I wanted to be conservative in my
> conservatism.  If folks think 2/3 is more appropriate (and consistent
> with syntax changes), I'm happy to change this number before we move
> to voting phase.
>
> -Sara
>
> Or, as Ze'ev once famously said, "Give the language a rest".
>

+1 on this, though I would strongly recommend to use a 2/3 threshold for
all RFCs, be they language, library or procedural. We're having this
discussion on nearly every single RFC (seriously, even the UUID RFC which
is as non-language as these things get had arguments about this) and this
would be a good chance to simplify the rules.

I would also explicitly note that the voting threshold applies to the
primary RFC vote only, while secondary votes are simple majority votes.

Nikita

Re: [PHP-DEV] Re: [RFC][Discuss] Increase non-syntaxruntime-impactingRFC votingthreshold to 60%

2017-09-13 Thread Christoph M. Becker 
On 14.09.2017 at 00:08m, Zeev Suraski wrote:

> On 14 Sep 2017, at 1:03, Christoph M. Becker 
> mailto:cmbecke...@gmx.de>> wrote:
> 
> On 13.09.2017 at 23:38, Zeev Suraski wrote:
> 
> -Original Message-
> From: Christoph M. Becker [mailto:cmbecke...@gmx.de]
> Sent: Thursday, September 14, 2017 12:25 AM
> To: Sara Golemon mailto:poll...@php.net>>; PHP internals 
> mailto:internals@lists.php.net>>
> Subject: [PHP-DEV] Re: [RFC][Discuss] Increase non-syntax runtime-impacting
> RFC votingthreshold to 60%
> 
> FTR: Zeev has also started preparing an RFC which includes this voting
> threshold, besides further issues: .
> 
> Oh wow, I was hoping to bake it for a while longer before public scrutiny :)
> 
> If you want to hide changes from , you
> have to mark them as "Minor Changes" (right below the "Edit summary").
> 
> I'm not into hiding, it's not confidential, just wasn't quite ready for the 
> spotlight just yet, especially as I won't be around to discuss it for over a 
> month :)

I didn't want to bring it into the spotlight – I just wanted to avoid
having two partially overlapping RFCs going unnoticed by the respective
authors.  That's also why I've snipped most parts of your previous
reply, even though I'd have to say something about it. :)

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][Discuss] Increase non-syntaxruntime-impacting RFC votingthreshold to 60%

2017-09-13 Thread Zeev Suraski 

On 14 Sep 2017, at 1:03, Christoph M. Becker 
mailto:cmbecke...@gmx.de>> wrote:

On 13.09.2017 at 23:38, Zeev Suraski wrote:

-Original Message-
From: Christoph M. Becker [mailto:cmbecke...@gmx.de]
Sent: Thursday, September 14, 2017 12:25 AM
To: Sara Golemon mailto:poll...@php.net>>; PHP internals 
mailto:internals@lists.php.net>>
Subject: [PHP-DEV] Re: [RFC][Discuss] Increase non-syntax runtime-impacting
RFC votingthreshold to 60%

FTR: Zeev has also started preparing an RFC which includes this voting
threshold, besides further issues: .

Oh wow, I was hoping to bake it for a while longer before public scrutiny :)

If you want to hide changes from , you
have to mark them as "Minor Changes" (right below the "Edit summary").

I'm not into hiding, it's not confidential, just wasn't quite ready for the 
spotlight just yet, especially as I won't be around to discuss it for over a 
month :)

Zeev

Re: [PHP-DEV] Re: [RFC][Discuss] Increase non-syntaxruntime-impacting RFC votingthreshold to 60%

2017-09-13 Thread Christoph M. Becker 
On 13.09.2017 at 23:38, Zeev Suraski wrote:

>> -Original Message-
>> From: Christoph M. Becker [mailto:cmbecke...@gmx.de]
>> Sent: Thursday, September 14, 2017 12:25 AM
>> To: Sara Golemon ; PHP internals 
>> Subject: [PHP-DEV] Re: [RFC][Discuss] Increase non-syntax runtime-impacting
>> RFC votingthreshold to 60%
>>
>> FTR: Zeev has also started preparing an RFC which includes this voting
>> threshold, besides further issues: .
> 
> Oh wow, I was hoping to bake it for a while longer before public scrutiny :)

If you want to hide changes from , you
have to mark them as "Minor Changes" (right below the "Edit summary"). :)

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: [RFC][Discuss] Increase non-syntax runtime-impacting RFC votingthreshold to 60%

2017-09-13 Thread Zeev Suraski 
> -Original Message-
> From: Christoph M. Becker [mailto:cmbecke...@gmx.de]
> Sent: Thursday, September 14, 2017 12:25 AM
> To: Sara Golemon ; PHP internals 
> Subject: [PHP-DEV] Re: [RFC][Discuss] Increase non-syntax runtime-impacting
> RFC votingthreshold to 60%
> 
> On 13.09.2017 at 22:42, Sara Golemon wrote:
> 
> > https://wiki.php.net/rfc/rfc.voting-threshold
> >
> > This topic has come up on the mailing list a few times, so I'd like to
> > formally open the topic for discussion.
> >
> > I'm generally pretty liberal when it comes to allowing the PHP
> > language to evolve and explore its identity, but the truth is a
> > feature that has 30 people vote against it and 31 people vote in favor
> > of it is not a mandate by any stretch of the imagination.  It's an
> > opportunity to examine why a divide exists and if we're all being
> > honest with each other, improve the original idea before it becomes a
> > maintenance burden.
> 
> Thanks for taking the initiative on this!
> 
> FTR: Zeev has also started preparing an RFC which includes this voting
> threshold, besides further issues: .


Oh wow, I was hoping to bake it for a while longer before public scrutiny :)  
Still a lot of work to go on it.

Realistically I'm only going to bring it up for discussion sometime around late 
October because I'm actually going to be off the grid for most of the 2nd half 
of September and most of October.

> IMHO, a 2/3 majority would be most suitable for any changes to php-src.
> Most votes have even been clearer, and I believe most (if not all) which would
> have failed a 2/3 threshold would have failed 60% as well.  (Zeev presented
> more detailed stats on this list a while ago.)  Having a 2/3 threshold for 
> all php-
> src change related votes would at least avoid the discussion into which 
> category
> the vote falls, though.

I agree, and the only exception that may make sense is the addition of 
functionality under an extension's namespace/pseudo namespace.  E.g., I'm not 
sure we need a 2/3 vote for a new oci8_*() function, or a new method added to 
ext/mysqli.  There are no downwards compatibility considerations, and it seems 
reasonable enough that the subject matter experts (the extension maintainers) 
will be given jurisdiction here.  To be honest, I'm not sure we need a vote at 
all for those, 2/3 or otherwise.  But this is pretty much the only example I 
can think of.

That said, I do think that if we finally have the mental strength and stamina 
to tackle the laconic 2011 Voting RFC, we should tackle it more thoroughly and 
try to solve as many of the issues that came up over the years.  This is what 
I'm attempting to do in the RFC I started drafting a couple of days ago - and 
that I'm NOT YET PUBLICLY DISCUSSING :)

Zeev

Re: [PHP-DEV] [RFC] [Discussion] JSON_THROW_ON_ERROR

2017-09-13 Thread Andrea Faulds 

Hi Jakub,

I already replied to you off-list, but for the benefit of people on-list…

Jakub Zelenka wrote:

On Sun, Sep 10, 2017 at 2:24 AM, Andrea Faulds  wrote:


Hi everyone,

Craig Duncan previously sparked discussion here about JSON's
error-handling behaviour. Unfortunately, his attempt to change it seems not
to have gone anywhere, but I have his blessing to try this other approach
instead.

So here's an RFC: https://wiki.php.net/rfc/json_throw_on_error

The feature can be described in a single paragraph (in fact, the title is
pretty much enough, the patch is just detail) but it's better to go through
the proper RFC process.

Please tell me what you think.



I think that it makes sense in general. There are just couple of things
that are not described in RFC.

Currently it has higher priority than JSON_PARTIAL_OUTPUT_ON_ERROR. I think
that if someone specify this constant, then the partial output is required
and it should be preferred. In any case I think it should be in the RFC
what the behavior is.


Per your suggestion, this has been changed so 
JSON_PARTIAL_OUTPUT_ON_ERROR takes precedence. This means if you have a 
wrapper function that just adds a JSON_THROW_ON_ERROR flag, you can 
still use JSON_PARTIAL_OUTPUT_ON_ERROR. And the RFC mentions this.




Another thing is the logic of setting global json error. Currently it just
reset the error value so the next call to json_last_error() will return 0
(no error) even though there was an error which is in the exception code. I
think that the behavior should be either not resetting the global error
value at all (the previous error should be kept) or setting the global
error value so the json_last_error returns the same value as exception code
or 0 if no error. Again it would be good to mention the behavior in the RFC
so we prevent a new discussion in the PR... :)


I'm not sure what to do here. I want code to use one error mechanism or 
the other, not both, so I don't want JSON_THROW_ON_ERROR to also set the 
global error code. I decided to reset it to no error because there's no 
previous error that needs handling by error-checking code, the exception 
takes care of that. But I can see where you're coming from with the idea 
of not touching it at all.


Thanks.



Cheers




--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][Discuss] Increase non-syntax runtime-impacting RFC votingthreshold to 60%

2017-09-13 Thread Christoph M. Becker 
On 13.09.2017 at 22:42, Sara Golemon wrote:

> https://wiki.php.net/rfc/rfc.voting-threshold
> 
> This topic has come up on the mailing list a few times, so I'd like to
> formally open the topic for discussion.
> 
> I'm generally pretty liberal when it comes to allowing the PHP
> language to evolve and explore its identity, but the truth is a
> feature that has 30 people vote against it and 31 people vote in favor
> of it is not a mandate by any stretch of the imagination.  It's an
> opportunity to examine why a divide exists and if we're all being
> honest with each other, improve the original idea before it becomes a
> maintenance burden.

Thanks for taking the initiative on this!

FTR: Zeev has also started preparing an RFC which includes this voting
threshold, besides further issues: .

> Please note the "Open Question".  I'm not all that sure 60% is enough
> of a mandate either, but I wanted to be conservative in my
> conservatism.  If folks think 2/3 is more appropriate (and consistent
> with syntax changes), I'm happy to change this number before we move
> to voting phase.

IMHO, a 2/3 majority would be most suitable for any changes to php-src.
Most votes have even been clearer, and I believe most (if not all) which
would have failed a 2/3 threshold would have failed 60% as well.  (Zeev
presented more detailed stats on this list a while ago.)  Having a 2/3
threshold for all php-src change related votes would at least avoid the
discussion into which category the vote falls, though.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC][Discuss] Increase non-syntax runtime-impacting RFC voting threshold to 60%

2017-09-13 Thread Sara Golemon 
https://wiki.php.net/rfc/rfc.voting-threshold

This topic has come up on the mailing list a few times, so I'd like to
formally open the topic for discussion.

I'm generally pretty liberal when it comes to allowing the PHP
language to evolve and explore its identity, but the truth is a
feature that has 30 people vote against it and 31 people vote in favor
of it is not a mandate by any stretch of the imagination.  It's an
opportunity to examine why a divide exists and if we're all being
honest with each other, improve the original idea before it becomes a
maintenance burden.

Please note the "Open Question".  I'm not all that sure 60% is enough
of a mandate either, but I wanted to be conservative in my
conservatism.  If folks think 2/3 is more appropriate (and consistent
with syntax changes), I'm happy to change this number before we move
to voting phase.

-Sara

Or, as Ze'ev once famously said, "Give the language a rest".

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

2017-09-13 Thread Sara Golemon 
On Wed, Sep 13, 2017 at 8:59 AM, Tony Marston  wrote:
> "Sara Golemon"  wrote in message
> news:CAESVnVpUkM_W9xF+0Qt=2M61dGy40gtOehFo=u_f3gd87rm...@mail.gmail.com...
>> +0.1 to removing case-insensitive constants, though we'd need to
>> define both "null" and "NULL" (similar for true and false) since
>> there's little consensus on which version of these constants get used
>> from project to project.  Also: While deprecating for 7.3 is fine, I'd
>> favor waiting for 8.0 for full removal.
>>
>> As to François' suggestion to make the whole language case-sensitive?
>> Yeesh, that feels like a much more aggressive movement.  In the case
>> of constants they very nearly are case-sensitive only since, as you
>> point out, common practice is to not pass true for that third
>> parameter, and to prefer `const` over `define` anyway.  Identifiers
>> are another matter since they're insensitive by default.
>>
>> In the case of classnames I could almost get on board since
>> autoloading standards have pushed users naturally in the direction of
>> respecting case sensitive as a coding standard.  I don't feel as
>> though that's true of functions or of projects where autoloaders
>> aren't used (not a small number).
>
>
> You seem to forget that autoloading is an option, not a requirement.
>
I don't forget any such thing.  I noted it as a phenomenon which has
*pushed* users in a particular direction, but by no means have all
users gone that way, as you note about yourself. Indeed, I have a 10
year old framework still in use at a previous company which does many
similar things for many similar reasons.

I also stated that I could *almost* get on board.  Almost is not 100%,
it's arguably not even 50% since it implies not actually crossing some
minimum required threshold.

> - I don't like the way autoloaders work - all my class names are in snake
> case (lowercase with underscore separators) and the autoloader converts '_'
> into '/' thus producing a file path which does not exist.
>
Nit; That's autoloader specific.  PSR-0 defines that behavior, but
PSR-4 does not, for example.

> By convention I always use uppercase for constants which makes them
> instantly recognisable in my code as all other names are either completely
> lowercase or mixed case. Making constants case sensitive instead of
> insensitive would not affect me.
>
Agreed, nor I suspect would it effect most other users regardless of
which case they use since the trend is to not use case-insensitive
constants in the first place.

> People who think that case sensitive software is cool are deluding
> themselves. When I started working on mainframe computers (UNIVAC and IBM)
> in the early 1970s everything was case-insensitive. This was only changed by
> people who did not understand the ramifications of their choice.
>
Yeah, decades of C/C++/Java developers are so dumb, like... fer reals.
Friggin' script kiddies, the lot of 'em.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

2017-09-13 Thread Tony Marston 
"Ryan Pallas"  wrote in message 
news:caobuzdtmhxq285hwmc3x9th2rj9d7ty3vnhnpcbzdceppch...@mail.gmail.com...


On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston 
wrote:






You seem to forget that autoloading is an option, not a requirement. I
don't use autoloading in my 14 year old framework for several reasons:
- An autoloader did not exist when I created my framework.
- I built an alternative mechanism into my framework, so I don't need an
autoloader.
- I don't like the way autoloaders work - all my class names are in snake
case (lowercase with underscore separators) and the autoloader converts 
'_'

into '/' thus producing a file path which does not exist.



I must be missing something, there is no autoloader shipped with PHP. You
have to define your own and register it. You can choose to change _ into /
within your autoloader, but that is entirely preference and not
specifically part of autoloading. For example, here's my autoloader which
does no such symbol replacement https://pastebin.com/rQRrXzCa




Then it must have been the project I was working on which used a combination 
of Codeigniter, Composer and PHPUnit. There was definitely something which 
translated a class name from "foo_bar_snafu" into "foo/bar/snafu". It's no 
wonder that I stopped using it.


--
Tony Marston

http://www.tonymarston.net
http://www.radicore.org 



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

2017-09-13 Thread Tony Marston 
"Levi Morrison"  wrote in message 
news:cafmt4nrc43y-nl_v85qt7jgv1ohm0y4kexhb4e3mi1ejhj0...@mail.gmail.com...


On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston  
wrote:

People who think that case sensitive software is cool are deluding
themselves. When I started working on mainframe computers (UNIVAC and 
IBM)
in the early 1970s everything was case-insensitive. This was only changed 
by

people who did not understand the ramifications of their choice.


Actually there are concrete bugs caused by case insensitivity. For one
example, here is our own bugs.ph p.net report about a Turkish locale
issue:

   https://bugs.php.net/bug.php?id=18556

The short summary of the issue is that when capital `I`, the ninth
letter of the English alphabet, is lowercased in the Turkish locales
it does not become the same `i` as it does in English but a different
i that is not considered equal. Thus classes such as `Iterator` are
not found in the Turkish locales. Note that this bug was fixed, and
then there was a regression that lasted until PHP 5.5.

There are other case insensitivity bugs but this Turkish one is the
poster child and if you search around you can find many examples of
it.

Case sensitivity is thus *a correctness issue* and not a "cool"ness,
personal preference, performance, or some other type of issue. I argue
correctness and maintenance issues are the most important and thus if
we change sensitivity of *any* type of symbol it should go in the
direction of being case sensitive. Someone can disagree on what they
value but people who think case insensitivity is not a correctness
issue "are deluding themselves".

Levi Morrison


I'm sorry, but errors in translation from one character set to another are 
insignificant when compared with the much larger problem of the same word 
having diferent meanings depending on case. In the English language "info" 
is the same as "Info" is the same as "INFO" is the same as "iNFO" is the 
same as "iNfO" and so on. If the problem is that an English word cannot be 
recognised as the same word regardless of case when switching to a 
non-English character set then the issue is with switching to a non-English 
character set.


Introducing case sensitivity just for this minor bug would create more 
issues than it would solve, so this bug should be solved using a different 
technique .


--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

2017-09-13 Thread Ryan Pallas 
On Wed, Sep 13, 2017 at 8:06 AM, Rowan Collins 
wrote:

> On 13 September 2017 14:15:43 BST, Ryan Pallas 
> wrote:
> >I must be missing something, there is no autoloader shipped with PHP.
>
> Just to be pedantically correct, there actually is an implementation
> shipped, see http://php.net/spl_autoload It's even the default if you
> don't pass your own function to spl_autoload_register.
>

Almost 2 decades in PHP, and still so much I don't know haha. I will point
out though, that according to a comment [1] it does not replace the
underscores with slashes as mentioned, and I see no where in the code [2]
that it does either.

[1] http://php.net/manual/en/function.spl-autoload.php#98762
[2] https://github.com/php/php-src/blob/master/ext/spl/php_spl.c#L306


>
> Nonetheless, you are quite right that Tony's complaint is nonsensical,
> because he could implement whatever autoloader suited his directory
> structure, if he wanted to - even a case insensitive one.
>
> It is true that autoloading isn't mandatory, but it's also a complete
> straw man, because Sara already made the same point herself:
>
> > I don't feel as though that's true of ...
> > projects where autoloaders
> > aren't used (not a small number).
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

2017-09-13 Thread Levi Morrison 
On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston  wrote:
> People who think that case sensitive software is cool are deluding
> themselves. When I started working on mainframe computers (UNIVAC and IBM)
> in the early 1970s everything was case-insensitive. This was only changed by
> people who did not understand the ramifications of their choice.

Actually there are concrete bugs caused by case insensitivity. For one
example, here is our own bugs.php.net report about a Turkish locale
issue:

https://bugs.php.net/bug.php?id=18556

The short summary of the issue is that when capital `I`, the ninth
letter of the English alphabet, is lowercased in the Turkish locales
it does not become the same `i` as it does in English but a different
i that is not considered equal. Thus classes such as `Iterator` are
not found in the Turkish locales. Note that this bug was fixed, and
then there was a regression that lasted until PHP 5.5.

There are other case insensitivity bugs but this Turkish one is the
poster child and if you search around you can find many examples of
it.

Case sensitivity is thus *a correctness issue* and not a "cool"ness,
personal preference, performance, or some other type of issue. I argue
correctness and maintenance issues are the most important and thus if
we change sensitivity of *any* type of symbol it should go in the
direction of being case sensitive. Someone can disagree on what they
value but people who think case insensitivity is not a correctness
issue "are deluding themselves".

Levi Morrison

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

2017-09-13 Thread Rowan Collins 
On 13 September 2017 14:15:43 BST, Ryan Pallas  wrote:
>I must be missing something, there is no autoloader shipped with PHP.

Just to be pedantically correct, there actually is an implementation shipped, 
see http://php.net/spl_autoload It's even the default if you don't pass your 
own function to spl_autoload_register.

Nonetheless, you are quite right that Tony's complaint is nonsensical, because 
he could implement whatever autoloader suited his directory structure, if he 
wanted to - even a case insensitive one.

It is true that autoloading isn't mandatory, but it's also a complete straw 
man, because Sara already made the same point herself:

> I don't feel as though that's true of ...
> projects where autoloaders
> aren't used (not a small number).

Regards,

-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

2017-09-13 Thread Lester Caine 
On 13/09/17 09:59, Tony Marston wrote:
> People who think that case sensitive software is cool are deluding
> themselves. When I started working on mainframe computers (UNIVAC and
> IBM) in the early 1970s everything was case-insensitive. 

Life was so much easier when using an RTTY as the keyboard and printer.
No one had invented the shift key and the 5 bit character set was easy
to work with.

-- 
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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

2017-09-13 Thread Rowan Collins 
Regards,
On 12 September 2017 21:35:51 BST, Levi Morrison  wrote:
>On Tue, Sep 12, 2017 at 11:59 AM, Rowan Collins
> wrote:
 If we want function and class references, they should have their
>own,
unambiguous, syntax.
>>
>> I stand by this assertion. Consider the following statement:
>>
>> $foo = bar;
>>
>> Even if "bar" cannot *simultaneously* be the name of a function, a
>class, and a constant, it can still *potentially* be any of the three,
>from the point of view of the compiler.
>
>If it's known, it's known, and it can proceed with that type. If it's
>not known then autoload and proceed like normal. I fail to see how
>this is an issue, and in fact, see it as a *significant* improvement
>to our current situation...


If the symbol tables had always been unified, I guess you could think of a 
function name as a constant whose value happened to be of type IS_FUNC - like 
how in JS "function foo() {}" and "var foo = function{}" are very nearly 
interchangeable. But it feels like retrofitting that onto the existing language 
would be messy.

For instance, an autoloader would have to be given a token name, with no 
context of whether it's expected to be a class, function, or constant. (Of 
course we'd have to solve the dilemma of how global function fallback/shadowing 
should interact with autoloading first.) Users would have to learn this concept 
of an untyped token, because the error message they'd get if it wasn't defined 
could no longer say "undefined constant".

Then there's all the existing support for string-based callables. I can't 
actually think of any cases that are unresolvable, but there's some odd 
implications:

function foo() { echo 'Hello, world!'; }
const bar='foo';
$fn = bar;
$fn(); // already works
bar(); // would this work? if not, why not, since it's no longer ambiguous?
const baz='bar';
$fn2 = baz;
$fn2(); // in which case, would this also work?
baz(); // and then what about this?

I feel like this could lead to confusion either way, and just increase the 
complexity for both human and machine analysis.

Then there's other symbol tables that would need to be unified - we'd want 
$foo->bar be able to grant a method reference, and Foo::bar a static method 
reference. Just how much code is it worth breaking to allow this syntax?

It feels a lot cleaner to say "function and class references are a new concept, 
and you'll know when you're using them because they look like this". Something 
like "SomeClass::classref", "some_func::funcref", 
"SomeClass::someStaticMethod::funcref", "$some_object->someMethod::funcref".
 
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

2017-09-13 Thread Ryan Pallas 
On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston 
wrote:

>
>>
> You seem to forget that autoloading is an option, not a requirement. I
> don't use autoloading in my 14 year old framework for several reasons:
> - An autoloader did not exist when I created my framework.
> - I built an alternative mechanism into my framework, so I don't need an
> autoloader.
> - I don't like the way autoloaders work - all my class names are in snake
> case (lowercase with underscore separators) and the autoloader converts '_'
> into '/' thus producing a file path which does not exist.
>

I must be missing something, there is no autoloader shipped with PHP. You
have to define your own and register it. You can choose to change _ into /
within your autoloader, but that is entirely preference and not
specifically part of autoloading. For example, here's my autoloader which
does no such symbol replacement https://pastebin.com/rQRrXzCa


>
> By convention I always use uppercase for constants which makes them
> instantly recognisable in my code as all other names are either completely
> lowercase or mixed case. Making constants case sensitive instead of
> insensitive would not affect me.
>
> However, I would be totally against switching the rest of the language to
> be case sensitive for the following reasons:
> - It would be a huge BC break no little or no benefit.
> - It would allow developers to shoot themselves in the foot by having
> different functions with the same name but different mixtures of case, so
> that foo(), Foo() FOO() and fOO() would be treated as different functions.
> - if people move from keyboard input to speech recognition, then simply
> speaking a name would not work - you would have to spell it out character
> by character, and specify either upper or lowercase for each character.
>

This is about deprecating the third parameter in define, so userland
constants defined by this function cannot be case insensitive. As mentioned
before by Christoph this is not an attempt to change case sensitivity for
other identifiers (functions, classes, etc) even if it was brought up
before. That is not his intention here, and we need to stick to the focus
of this RFC.


> People who think that case sensitive software is cool are deluding
> themselves. When I started working on mainframe computers (UNIVAC and IBM)
> in the early 1970s everything was case-insensitive. This was only changed
> by people who did not understand the ramifications of their choice.
>
> --
> Tony Marston
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

2017-09-13 Thread Tony Marston 
"Sara Golemon"  wrote in message 
news:CAESVnVpUkM_W9xF+0Qt=2M61dGy40gtOehFo=u_f3gd87rm...@mail.gmail.com...


On Tue, Sep 12, 2017 at 5:02 AM, Christoph M. Becker  
wrote:

Even if these issues could be resolved, I still think allowing both
case-sensitive and case-insensitive constant identifiers does more harm
than good.


+0.1 to removing case-insensitive constants, though we'd need to
define both "null" and "NULL" (similar for true and false) since
there's little consensus on which version of these constants get used
from project to project.  Also: While deprecating for 7.3 is fine, I'd
favor waiting for 8.0 for full removal.

As to François' suggestion to make the whole language case-sensitive?
Yeesh, that feels like a much more aggressive movement.  In the case
of constants they very nearly are case-sensitive only since, as you
point out, common practice is to not pass true for that third
parameter, and to prefer `const` over `define` anyway.  Identifiers
are another matter since they're insensitive by default.

In the case of classnames I could almost get on board since
autoloading standards have pushed users naturally in the direction of
respecting case sensitive as a coding standard.  I don't feel as
though that's true of functions or of projects where autoloaders
aren't used (not a small number).


You seem to forget that autoloading is an option, not a requirement. I don't 
use autoloading in my 14 year old framework for several reasons:

- An autoloader did not exist when I created my framework.
- I built an alternative mechanism into my framework, so I don't need an 
autoloader.
- I don't like the way autoloaders work - all my class names are in snake 
case (lowercase with underscore separators) and the autoloader converts '_' 
into '/' thus producing a file path which does not exist.


By convention I always use uppercase for constants which makes them 
instantly recognisable in my code as all other names are either completely 
lowercase or mixed case. Making constants case sensitive instead of 
insensitive would not affect me.


However, I would be totally against switching the rest of the language to be 
case sensitive for the following reasons:

- It would be a huge BC break no little or no benefit.
- It would allow developers to shoot themselves in the foot by having 
different functions with the same name but different mixtures of case, so 
that foo(), Foo() FOO() and fOO() would be treated as different functions.
- if people move from keyboard input to speech recognition, then simply 
speaking a name would not work - you would have to spell it out character by 
character, and specify either upper or lowercase for each character.


People who think that case sensitive software is cool are deluding 
themselves. When I started working on mainframe computers (UNIVAC and IBM) 
in the early 1970s everything was case-insensitive. This was only changed by 
people who did not understand the ramifications of their choice.


--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php