Re: [PHP-DEV] semicolon terminator for switch cases

[Benoit SCHILDKNECHT]

Le Thu, 26 Mar 2020 21:28:38 +0100, Stanislav Malyshev
 a écrit:


Hi!

On 3/26/20 1:26 PM, David Rodrigues wrote:

I agree with Tovilo. It is weird and confusing. Actually I never know
that it was possible.


You seem to contradict yourself - if you never knew it was possible, how
could you ever be confused by it?



OK, I'm often lurking, but I have to react to this. I never knew it was
possible too, but I am also confused by this. A semi-colon is terminal. It 
always is. "You see this set of instructions? Done.". But in this case, it 
is not. You see the problem?


--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

[PHP-DEV] Re: [RFC] Mixed Typehint

[Benoit Schildknecht]

Le Tue, 19 Dec 2017 04:34:24 +0100, Michael Moravec   
a écrit:



Hello internals,

I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
https://wiki.php.net/rfc/mixed-typehint

The purpose of this RFC is to introduce "mixed" typehint on language  
level

to be used
as a valid typehint. PHP currently forces users to not use any type in  
case

the
type is mixed/unclear. This makes code inconsistent and less explicit.  
With

mixed,
it should be easy to eliminate this inconsistency and achieve fully type
hinted code.
It's a simple alias for the current behavior of no type and is fully
interchangeable.
This is mostly cosmetic change, no BC break to user-land is involved.

This RFC comes with a rather simple PR:
https://github.com/php/php-src/pull/2603

Please let me know what you think or if you find anything unclear.

Thanks!
Michael Moravec



It would be a +1 for me. Typehinting "mixed" tells way more than no  
typehinting at all. Because legacy code.


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

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

[Benoit Schildknecht]

Le Fri, 02 Dec 2016 14:54:04 +0100, Matteo Beccati  a  
écrit:



On 02/12/2016 08:36, Thomas Nunninger wrote:

Hi,


So, if I only want to get the emulated prepared statement, I have to do
ob_start()/ob_get_clean(), then use a regexp to fetch it ? I want v1
back T_T


I second that. Why do you print it directly? Wouldn't it be better to
return a structured array with the information needed? If needed, you
can var_dump() the array yourself.


Could you please explain what's the use case? As far as I'm concerned
such information would only be useful during PDO driver development,
phpt files and bug reporting / fixing.


Cheers


It's pretty simple : debugging and optimizing scripts and statements. I've  
lost hours, manually emulating tons of statements, or trying to guess  
what's happening when I have something like 1000+ prepared values (mass  
insert). And since I have to do it by hand, mistakes happen, so I lose  
even more time debugging my emulations. Having a direct access to the  
emulated statements, without having to dirtily parse a dump, will be a  
huge plus for me, my team and the performances of my debug component.


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

[PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

[Benoit Schildknecht]

Le Thu, 17 Nov 2016 23:19:38 +0100, Adam Baratz  a  
écrit:



Hi,

Based on my second thoughts on my initial approach, I created an RFC to
supplant it:
https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation_v2

I believe this better addresses the negative feedback from the original
RFC[1] and is a better solution to the problem.

Thanks,
Adam

---
[1] https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation


So, if I only want to get the emulated prepared statement, I have to do  
ob_start()/ob_get_clean(), then use a regexp to fetch it ? I want v1 back  
T_T


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

[PHP-DEV] Re: [RFC][Vote] Typed Properties

[Benoit Schildknecht]

Hi,

Is it 2/3+1 or 1/2+1 ? I haven't seen it in the RFC.

Cheeers.

Le Fri, 10 Jun 2016 12:38:04 +0200, Joe Watkins  a  
écrit:



Afternoon internals,

The vote for typed properties has been restarted.

Please take part: https://wiki.php.net/rfc/typed-properties

Cheers
Joe



--
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Benoit Schildknecht]

Le Wed, 25 May 2016 21:40:28 +0200, Fleshgrinder  a  
écrit:



and unset simply because the property is not
explicitly assigned null by unset, it is being undefined.



Because null !== undefined. That's why you get an error after an  
unset($this->var), and you don't get one after $this->var = null; . "$var  
= null;" and "unset($var)" are totally different, it has been like that  
for years. If you want to change this behavior, propose an RFC, and make  
it approve. But meanwhile, you'll have to keep this in mind : "null" is a  
value. While "unset" does not affect a value, it deletes the variable, it  
deletes any references of the variable it targets, the variable doesn't  
exist anymore. With unset, the variable is dead. With null, it has  
amnesia. I can't find any better analogy.


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

Re: [PHP-DEV] [RFC] PHP Attributes

[Benoit Schildknecht]

If I was a popular framework creator, this wouldn't stop me. I would  
release two packages : one for 7.0, another one for 7.1. And the 7.0 one  
would be the 7.1 one that has been processed through a script to remove  
any <<>> syntax, or to transform it (if pre/post attributes instructions  
were to be implemented in the core).


Regards,
Ben.

Le Sun, 24 Apr 2016 01:09:08 +0200, "Thomas Bley"  a  
écrit:


The <<>> syntax comes with the problem that previous versions cannot  
ignore it on parsing.
So poeple write new frameworks for 7.0 which cannot be parsed in 5.x,  
then they write new frameworks for 7.1 which cannot be parsed with 7.0  
and 5.x and so on.
For companies staying on Linux distributions with long term support on  
7.0, this is rather a nightmare for both users and framework maintainers.
When choosing <<>> or any other non-backward compatible syntax for 7.1,  
there should be a patch for 7.0 to ignore the new syntax without parse  
errors.


Regards
Thomas

Fleshgrinder wrote on 23.04.2016 17:29:


+1 for the basic idea, however, I have various remarks.

The RFC text is hard to read and contains many grammatical mistakes. How
could one help you here?

I think that the Hack name attributes is unintelligible and annotations
would be much clearer to any audience. Simply because the name is very
well known.

I do not see the need for multi-annotation nor multi-value support. It
just creates multiple ways to achieve the exact same thing for no good
reason.

I do not like the <<>> syntax. It requires many key strokes, is hard to
read, and looks ugly. Why not simply @ and be done with it. I am not so
sure about the bracket requirement, is it somehow required for the
parsing? Otherwise I would leave it off. I guess it might be hard to
find the end of an annotation but have you considered to use the
semicolon for that? Would align nicely with existing PHP syntax. The
following would be the ABNF for my proposal:

ANNOTATION= "@" NAME [ " " VALUE ]
NAME  = STRING
VALUE = QUOTED-STRING / PHP-CONSTANT / EXPRESSION
QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE )
EXPRESSION= PHP-CODE ";"

A semicolon would only be required if it is not a single quoted string
(see following example) or constant. A question that I see unanswered is
how embedding of variables in quoted strings should be dealt with. I see
no need for this but people might assume it is supported because PHP
supports it everywhere else.

"
class A {}

<")>>
class B {}

?>

Requiring PHP code to be terminated with a semicolon should also ensure
that people do not start to write fully-fledged programs in annotations.
Since that is not what they are intended for. An alternative approach I
see here would be to go for the brackets but then again only for PHP  
code:


EXPRESSION = "(" PHP-CODE ")"

Then again, it looks similar to a function call and this is imho not
good. Unless of course new annotations can be defined as special
functions directly in userland, e.g. with an `annotation function`
and/or `annotation class`. However, this would require more thought.

Another question that is unanswered for me is: how to go about adding
annotations to a complete file as is currently possible with PhpDoc and
its file-level doc block:

'
@copyright '2016 Richard Fussenegger'
@license 'MIT'

declare(strict_types=1);

namespace Fleshgrinder\PhpInternals;

@description 'True annotation support could be a very good thing.'
@invariant $this->balance >= self::MIN_BALANCE;
class Account {

 private const int MIN_BALANCE = 0;

 private int $balance;

 private Person $owner;

 @require $sum >= 0;
 @ensure $this->balance === (old::$balance + $sum);
 public function deposit(int $sum): void {
   $this->balance += $sum;
 }

 @require $sum >= 0;
 @require $sum <= $this->balance - self::MIN_BALANCE;
 @ensure $this->balance === (old::$balance - $sum);
 public function withdraw(int $sum): void {
   $this->balance -= $sum;
 }

 @deprecated 'for various reasons'
 public function setOwner(Person $wner): void {
   $this->owner = $owner;
 }

}

@inheritDoc
class OverdraftAccount extends Account {

 private const int MIN_BALANCE = -1000;

}

?>

We also need to make sure to add something regarding coding standards
for annotation names. I would propose to go for camelCase (same as for
method names) since this is what PhpDoc used to use for many years now.

We also need to define how people can avoid to collide with internal
annotations. The typical double-underscore prefix approach that we have
for magic methods creates a lot of visual clutter and looks weird if
spread among all kinds of places. A namespace approach as we have it
already for userland code could help here.

 'user',
 'unique_constraints' => [
   'name' => 'user_unique',
   'columns' => [ 'username' ],
 ],
 'indexes' => [
   'name' => 'user_idx',
   'clumns' => [ 'email' ],
 ],
 'schema' => 'schema_name',
];
class User {}

?>

--
Richard "Fleshgrinder" Fussenegger







--
Utili

[PHP-DEV] Re: [RFC][DISCUSSION] Trailing commas in all list syntax

[Benoit Schildknecht]

Hi,

Le Tue, 03 Nov 2015 20:22:12 +0100, Sammy Kaye Powers  a  
écrit:



Hey internals!

The RFC to allow trailing commas to function calls & declarations has  
been
withdrawn in favor of the a RFC that broadens the scope to all list  
syntax.


https://wiki.php.net/rfc/list-syntax-trailing-commas

The RFC to allow trailing commas for all lists is now open for  
discussion.

:)

Thanks,
Sammy Kaye Powers
sammyk.me


I think it's a terrible idea :
- Another code style, another way to write code.
- It's not clean at all.
- Error source : when you put a comma, that's because you want to add  
something. How would you know if something hasn't been deleted by another  
person, if you forgot something, or if it is intended ?
- Some languages don't allow this. If I take the habit of putting trailing  
commas because that's an obligation from the company I'm working for, I'm  
likely to make mistakes in another languages, and so, be less productive,  
make more buggy code. Making my brain busy with "this is language X,  
remember, trailing commas aren't allowed in this one.".


I'd prefer to remove existing trailing commas support from the language,  
for PHP 8 (because of the BC), for language consistency.


My 0.02$ :)

Regards,

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

[PHP-DEV] Re: PHP 7.1 - should we add a random_str() function?

[Benoit Schildknecht]

Hi,

Le Wed, 30 Sep 2015 18:15:09 +0200, Scott Arciszewski  
 a écrit:



This is probably answerable by a quick yes/no and shouldn't need a ton
of bikeshedding, but if that happens anyway I apologize in advance.

I think random_bytes() and random_int() are great; they provide a
much-needed building block in PHP 7.0. However, I do worry a bit that
the most common use for random_int() (generating a random string of a
fixed length with a given character set) will be reinvented over and
over again, and rarely consistently.

I would propose a random_str() function that behaves similar to this
userland snippet: http://stackoverflow.com/a/32870871/2224584

Function prototype:


string random_str( int $length, string $charset)


Would return a string or throw an Error|Exception (e.g. invalid input
parameters, or the operating system's CSPRNG begins to melt).

I can write up an RFC for this, with a patch targeting 7.1, if anyone
is interested in it.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 


I'm interested, as I generate random strings for default passwords. I can  
stay with my current system, but it would be sweet to shorten my code a  
little bit :)


Regards.

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Benoit Schildknecht]

Le Sat, 19 Sep 2015 19:44:01 +0200, "François Laupretre"  
 a écrit:



Le 19/09/2015 14:25, Rowan Collins a écrit :


- a syntactic sugar for array_key_exists and property_exists, maybe  
called hasitem(); hasitem($foo['bar']) would check $foo has the item  
'bar', but hasitem($foo) would be an error


The most important, IMO, is a more intuitive, readable alternative to  
array_key_exists(). Checking the existence of a plain var is important  
for completeness and should be available, but remains an edge case, and  
property_exists() seems sufficient.


Anyway, the problem we have with names like 'exists' or 'hasitem', is  
that they would become reserved names. So, they couldn't be used as  
function/method names anymore, creating an important BC break.


Regards

François


What about the context sensitive lexer ? exists() would be reserved as a  
function name, but not more than that.


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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Benoit Schildknecht]

Le Fri, 18 Sep 2015 20:38:12 +0200, Rowan Collins  
 a écrit:



Benoit Schildknecht wrote on 18/09/2015 19:24:
I agree. exists() would allow PHP devs to make more secure, cleaner and  
lighter code. It fills a gap and would be useful to a lot of devs.


On the contrary, I think code using exists() would be extremely fragile,  
because it's highly resistant to refactoring, and encourages developers  
to leave variables uninitialised.


What makes cleaner, more secure code is always initialising your  
variables before using them - basically, what the "undefined variable"  
Notice is suggesting you do.


The examples Lester and Robert have come up with make sense in  
themselves, but are not architectures I would choose precisely because  
they are opaque (you have to remember what unset() and null mean) and  
hard to extend (there's no way to introduce a 4th state alongside the  
unset/null/value triad).


Obviously, all language features can be used to write bad code, but it  
seems much easier to write bad code than good using this proposed  
function.


Regards,


So there is a bug regarding variables and null. Because I don't get any  
notice if I use a variable with "null" as a value. If "null" means  
"uninitialized", how come there are no notices ?

And how come the null variable appear in get_defined_vars(), and disappear  
after an unset() ? Because null != undefined. The engine seems to consider  
null as a distinct state. Something that is not undefined. It is already  
like that, we are not theorizing.

 NULL
unset($foo);
var_dump(get_defined_vars()); // Good bye, foo

You have a lot of people who use isset() against null elements in an  
array. null elements happen a lot when interacting with an SQL server (for  
instance). I personally use array_key_exists(), but most people won't do  
the same at all. Because they think it is the same. And they'll forget,  
because isset() behaviour doesn't make sense, since null doesn't exactly  
behave as you say.


Using is_null() against a var to see if it is set and has a null value  
WILL trigger notices, and that's clearly not clean at all. In a production  
environment, you would like to get rid of them. All of them.


Taking advantage of set_error_handler() is out of question : how can you  
know if the triggered notice is related to a variable you expected to be  
declared with null ? Very hard task (if not impossible), and very heavy to  
implement.


And you have webservices, cURL, JSON, etc... All of these can give you  
"null" values. And it is not rare. This is not something we can correct.  
We have no control on this.


There are way more cases in which exists() would improve things A LOT. We  
need a native function that allows us to check this state WITHOUT  
triggering a notice.


Regards,

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

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

[Benoit Schildknecht]

Le Fri, 18 Sep 2015 19:40:50 +0200, Robert Williams  
 a écrit:



On Sep 18, 2015, at 10:27, Lester Caine  wrote:

All I am saying is that 'exists()' is simply part of the toolkit that
goes WITH extract(). There is a suitable tool in arrays and in objects
so why not complete the toolkit in straight variables. The names are a
mess between the three for many reasons and producing a complete new set
of function names has been another call, but there is a simple hole here
in a style of coding which there seems little logical reason NOT to  
fill.


Exactly, there’s clearly a gap here. Further, enough people want it that  
a few have shown up on this list, which means there are probably many,  
many thousands, or even millions, of people out in the wild that want  
it. I’m not familiar enough with PHP’s internals to say for sure, but I  
suspect it’s not terribly hard to implement (it’s just isset() without  
the extra null check). So… why not? Like anything else in the language,  
people don’t have to use it if they don’t want to, but it’s good to have  
tools. Yes, even tools that can be abused.


-Bob


I agree. exists() would allow PHP devs to make more secure, cleaner and  
lighter code. It fills a gap and would be useful to a lot of devs.


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

[PHP-DEV] Re: PHP 7.1 - Address PHPSadness #28?

[Benoit Schildknecht]

Bumping in (senior dev here).

I think this function must be implemented.

Every dev I've seen in my company use isset() as its name says it does :  
"Is this variable set, whatever its value is ?". That's exactly how we use  
it in the code. And we use "null" a lot too. For us, "null" is a value  
like another. The irony is, we set a variable to "null" mostly to avoid  
"Undefined variable" notices. To explain it shortly, when we see "$var =  
null;", we know that it is a variable that could not be changed in the  
scope.


It is logical (at least for us) that "isset()" returns true when a  
variable exists, even if its value is "null". I've yet to discover a  
security bug in our code, but we have very sensitive applications, in  
which we widely use "isset()". It could cause a lot of damages (maybe it  
already has, but haven't noticed yet), and "exists()" would prevent them.


Since we have "array_key_exists()", which is basically "exists()" for an  
array element, I don't see why "exists()" shouldn't be implemented. I  
don't see the logic here.


"isset()" and "empty()" wouldn't change, there couldn't any BC. Excepted  
for the userland code, in which there would already be an "exists()"  
function.


Regards,

Le Wed, 26 Aug 2015 05:09:43 +0200, Scott Arciszewski  
 a écrit:



Hi everybody,

Would anyone be interested in adding another helper like
isset()/empty() simply called exists() which would return true if the
variable is defined in the current scope (i.e. without raising an
E_NOTICE)?

It should be a simple change to add this function but it's too late
for 7.0 so, if there is any interest, I would respectfully put it off
until 7.1.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 



--
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/

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

Re: [PHP-DEV] Re: PHP 7.0.0alpha1 Released for Testing!

[Benoit Schildknecht]

Hi Anatol,

Thanks, it works like a charm :) And I had to install the x86 version of  
VS2015 (I had the x64 version only).


Regards,

Le Fri, 12 Jun 2015 21:32:00 +0200, "Anatol Belski"  
 a écrit:



Hi Benoit,

The builds was just repackaged, please redownload.

Thanks


-Original Message-----
From: Benoit Schildknecht [mailto:bensor...@neuf.fr]
Sent: Friday, June 12, 2015 9:19 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: PHP 7.0.0alpha1 Released for Testing!

Le Fri, 12 Jun 2015 02:53:48 +0200,  a écrit:

> Hi,
>
> The first alpha for 7.0.0 was just released and can be downloaded  
from:

>
> https://downloads.php.net/~ab/
>
> The Windows binaries are available at
>
> http://windows.php.net/qa/
>
> This is the start of a new PHP era! Thanks everyone who made and
> helped to make this happen. From now on we are looking straight
> forward to get the final in time.
>
> Please test it carefully, and report any bugs in the bug system.
> Alpha 2 will be tagged on Tuesday 23th and released on Thursday 25th.
>
> Regards,
> Kalle Sommer Nielsen, Anatol Belski and Ferenc Kovacs
>
Hi,

The php7apache2_4.dll is not included with the x86 TS windows binaries,  
and the

one from the snaps doesn't work, it makes my Apache crash :(

Regards.

--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe,  
visit:

http://www.php.net/unsub.php






--
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/

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

[PHP-DEV] Re: PHP 7.0.0alpha1 Released for Testing!

[Benoit Schildknecht]

Le Fri, 12 Jun 2015 02:53:48 +0200,  a écrit:


Hi,

The first alpha for 7.0.0 was just released and can be downloaded from:

https://downloads.php.net/~ab/

The Windows binaries are available at

http://windows.php.net/qa/

This is the start of a new PHP era! Thanks everyone who made and helped
to make this happen. From now on we are looking straight forward to get
the final in time.

Please test it carefully, and report any bugs in the bug system.
Alpha 2 will be tagged on Tuesday 23th and released on Thursday 25th.

Regards,
Kalle Sommer Nielsen, Anatol Belski and Ferenc Kovacs


Hi,

The php7apache2_4.dll is not included with the x86 TS windows binaries,  
and the one from the snaps doesn't work, it makes my Apache crash :(


Regards.

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

[PHP-DEV] Re: Soft-reserve "void" class name

[Benoit Schildknecht]

Le Tue, 19 May 2015 17:28:34 +0200, Nikita Popov  a  
écrit:



Hi internals!

For PHP 7 we soft-reserved a number of class names [1] like "numeric", so
that we have the ability to introduce them as typehints in a 7.x release.
"Soft" here means that we only document these names as being reserved and
don't throw an error when they're used.

I'd like to add "void" to this list, so we have the option to introduce a
void return type in PHP 7.x. I've seen some disagreement as to whether  
this
should be called "void" or "null" - this discussion should be held when  
an

RFC comes up, however we need to keep both options open until then.
(Currently only "null" is reserved.)

If people think that this requires a vote, I'll open one.

Thanks,
Nikita

[1] https://wiki.php.net/rfc/reserve_even_more_types_in_php_7



Hi,

While I'm impatient to see "void" in the engine, we should follow the  
process rules. This is something that have to go through an RFC. If we  
implement it, even a soft reservation, without following the process, it  
opens the door to all kind of dangerous situations.


So while I like your idea, it shouldn't be implemented before 7.1

Regards.

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

[PHP-DEV] Re: [VOTE][RFC] Coercive Scalar Type Hints

[Benoit Schildknecht]

Le Wed, 11 Mar 2015 16:10:44 +0100, Zeev Suraski  a écrit:


The vote on the Coercive Scalar Type Hints is now open for voting.



The latest version of the RFC includes changes discussed on internals@  
last

week:

1.  Accept string->bool and int->bool conversions (false->bool is not
supported)

2.  Accept leading/trailing spaces in string->number conversions.



wiki.php.net/rfc/coercive_sth

wiki.php.net/rfc/coercive_sth#vote



Thanks!



Zeev


Why hasn't it closed ? It's way past the 25th.

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

Re: [PHP-DEV] Proposal to delay 7.0 timeline

[Benoit Schildknecht]

Le Sat, 21 Mar 2015 18:44:23 +0100, Pierre Joye  a  
écrit:



On Mar 21, 2015 11:55 PM, "Zeev Suraski"  wrote:




Sent from my mobile

> On 21 במרץ 2015, at 18:05, Rasmus Lerdorf  wrote:
>
>> On 03/21/2015 08:52 AM, François Laupretre wrote:
>> Now, after more calls from many of you to delay it, and as Zeev  
himself

>> seemed to consider it as more acceptable, I am proposing again to

delay 7.0

>> feature freeze to May, 15 (2 month delay, date where vote is

starting). I
>> won’t repeat all the arguments of my previous posts but, to  
summarize,

it

>> would allow to include important features, making it a ‘real’ major

version.

>> Releasing a major version is not just a question of BC break, we also

need

>> to think about what we put forward. So, we need features. We already

have

>> STH, but we can do more (I personally have at least 4 RFCs I didn’t

have

>> time for, including scalar pseudo-methods, which can be an important
>> feature).
>
> No, please, let's get what we have stabilized and out the door. There
> are always more things to do and we can delay things indefinitely.  
And I

> completely disagree that this isn't a 'real' major version.

+1


Same.


Zeev


Same here, very bad idea

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

Re: [PHP-DEV] Request Feedback for Instance Variable Sugar RFC

[Benoit Schildknecht]

Hi,

I think your idea is good.

Le Mon, 09 Mar 2015 15:11:01 +0100, Shawn McCool  a  
écrit:


There's a cultural disposition against re-purposing a symbol from one  
major

version to the next. Let's consider that as fact and move on.

If I wanted to provide syntactic sugar to replace a symbol with $this->  
so
that our code can become more expressive if we choose to use it, how  
would

you recommend implementing that?

@ is not going to be a _real_ option. But what about..

:number = $number;

:add(:number, $number);

or some other character?


: is already used for ternary expression, it will confuse people as well  
as softwares and parsing scripts. The RFC would certainly be rejected in  
the voting phase.


I would recommend using § or £. I don't think they are actually used, and  
they are quite easy to remember.


Regards.

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

[PHP-DEV] Re: [RFC] [DISCUSSION] Consistent Function Names

[Benoit Schildknecht]

Hi,

I think the new functions must have consistent parameters order too. I  
think it is about the right time, so we'll have a cleaner and more logical  
language.


ATM, it's a real headache, we constantly have to read the documentation to  
make sure we give the arguments in the right order.


For instance
- implode() : "implode() can, for historical reasons, accept its  
parameters in either order. "

- strpos( $haystack, $needle )
- in_array( $needle, $haystack )

Regards.

Le Mon, 02 Mar 2015 22:52:03 +0100, Yasuo Ohgaki  a  
écrit:



Hi all,

First of all, I have no intention to remove nor deprecate old function
names.
Old function names must exist for compatibility and should be able to use
forever.

We have CODING_STANDARDS[1] for a long time.
However, PHP has so many functions that do not confirm this. Many of
violating functions can have standard conforming names safely

This RFC[2] proposes the CODING_STANDARDS confirmed function names.
The list[3] is almost complete, but improvement can be added. For  
example,

get_rusage() could be sys_get_rusage() because there is sys_getloadavg()
already.

There would not be much opinions for independent modules like BCMath, GD.
Please take a look for others and give your comments.

Thank you!

[1] https://github.com/php/php-src/blob/master/CODING_STANDARDS
[2] https://wiki.php.net/rfc/consistent_function_names
[3]
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed

--
Yasuo Ohgaki
yohg...@ohgaki.net



--
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/

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

[PHP-DEV] Re: Consistent function names

[Benoit Schildknecht]

Hi,

I like this idea. But I'm afraid of BC. There will be some scripts who  
won't work after that, because they already use functions with these names.


But since we already have some BC for PHP 7, I think it's about the right  
time to do this.


But we have to keep the old names for at least 2 or 3 major versions.  
Let's say :

- PHP 7 : We introduce the new functions names
- PHP 8 : We deprecate the old functions names
- PHP 9 : We delete the old functions names.

Regards.

Le Sun, 01 Mar 2015 12:29:49 +0100, Yasuo Ohgaki  a  
écrit:



Hi all,

First of all, I have no intention removing old function names.

PHP function names are subject of critics for a long time.
http://www.phpsadness.com/sad/4
http://www.phpsadness.com/sad/15
http://www.phpsadness.com/sad/27

How about rename all of these functions according to CODING_STANDARD for
PHP7
and have aliases for old names? Some names need complete rename, but  
most of

them are matter of adding "_".

Function names like phpversion(), htmlentities(), image*() shouldn't be
kept. IMHO.
(I repeat. I have no intention removing old names)

str*() would be most difficult. How about rename all of them to str_*()?
and keep
libc compatible alias names forever?

Thoughts?

It's last chance for PHP7.
Sorry that I bring up this topic again, but I couldn't resist.
If there isn't many objections, I'll write RFC and do all the work  
needed.


Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net



--
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/

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

[PHP-DEV] Re: [RFC][Discussion] In Operator

[Benoit Schildknecht]

Le Fri, 20 Feb 2015 13:54:26 +0100, Niklas Keller  a écrit:


Hi internals,

"In Operator" is now in discussion phase.

It would really make sense to vote on this RFC after there has been a
vote on https://wiki.php.net/rfc/context_sensitive_lexer.

Regards, Niklas


I agree. Context Sensitive Lexer have to be voted first.

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

Re: [PHP-DEV] RFC Proposal

[Benoit Schildknecht]

Hi Tim,

Le Wed, 18 Feb 2015 10:44:20 +0100, Tim Bezhashvyly  
 a écrit:



Dear internals,

my RFC was not about dropping just class constants but constants in  
general. Now I realise that you are not ready for this and most likely  
will never be. Thus I’m withdrawing my proposal.


Regards,
Tim


I'm totally against dropping the constants. Constants are one of the first  
things you learn in PHP, and they are literally everywhere. This would be  
a major BC. Even worse than DbC, return types and scalar type hints  
altogether. But the immutable variables are interesting.


As other people said, you should proceed step-by-step. I can perfectly see  
the immutable variables pass, but not the removal of the constants.


You should explain precisely what you have in mind, so we can discuss it.

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

Re: [PHP-DEV] Reviving scalar type hints

[Benoit Schildknecht]

Le Tue, 17 Feb 2015 00:58:18 +0100, Sara Golemon  a écrit:

On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre   
wrote:
Once again, anyone can take over version 0.3, if it is so great. Why  
don't you do it ?

I will play the game, stop working on my proposal, and vote 'yes' again.
But don't ask me to do it in your place.


If nobody else does it, I will.

I think Andrea's 0.3 proposal was extremely well balanced, served
everyone's needs whether they would admit it or not, and who's only
failing (subjectively termed) was the use of declare().  I think
declare() is fine and not nearly as ugly as some have slandered it to
be, but I'm willing to read the winds and modify it for v0.4.

Straw poll:
1) 

I like 2) No possible confusion, and it's a clear tag.

But implementing 3) would be a good thing, since it is Hack syntax. Even  
if I don't like to use comments to enable something.


If we have 2 similar features between PHP and Hack, I think it should have  
the same syntax, so there are minimum BC from one language to another, and  
people would spend less time to remember which syntax is the right syntax  
for PHP or Hack.


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

[PHP-DEV] Re: [RFC] Void Return Type

[Benoit Schildknecht]

Hi Andrea,
Le Sat, 14 Feb 2015 04:18:28 +0100, Andrea Faulds  a écrit:


Hi everyone,

I’ve written a small RFC and patch to add a “void” return type:

https://wiki.php.net/rfc/void_return_type

Please have a read over it. I think this would be a simple, yet useful  
addition.




Yup, totally useful, I use "void" a lot in other languages, it would be a  
nice addition to the language. I like this RFC.


Regards,
Benoit.

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

[PHP-DEV] Re: [RFC] Exceptions in the engine

[Benoit Schildknecht]

Hi,

Le Sat, 14 Feb 2015 00:25:12 +0100, Nikita Popov  a  
écrit:



The question of whether EngineException should inherit from Exception is
something we do have to consider now. Personally I prefer not introducing
any special exception types that aren't caught by default. I think that
would only make sense for errors that could occur literally everywhere
(like memory limit or timeout), but these are not handled by this RFC for
technical reasons. If someone has a strong opinion on this, I might make  
it

a voting option.

Commentary on these, and also any other relevant points is very welcome!

Thanks,
Nikita



I don't think EngineException should inherit from Exception, it would be  
very dangerous. I'm sure a lot of exceptions are handled like this by a  
lot of devs, without creating custom exceptions :


try {

} catch ( Exception $e ) {

}

Making EngineException inherit from Exception means that there is a chance  
it will change the behavior of this kind of code, maybe breaking some  
crucial datas in database or such.


Instead, I think Exception should inherit from EngineException. Or  
anything else.


Regards,
Benoit.

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

[PHP-DEV] Re: [DISCUSSION] Make empty() a Variadic

[Benoit Schildknecht]

Hi,
Le Thu, 12 Feb 2015 19:55:09 +0100, Thomas Punt  a  
écrit:



Hello PHP Internals!
I'd like to propose to make empty() a variadic, where if any arguments  
passed in are considered empty, then false is returned - otherwise  
return true.


I absolutely love this idea, and would make a good use of such an  
improvement.


Regards,
Benoit.

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

Re: [PHP-DEV] Design by Contract

[Benoit SCHILDKNECHT]

Hi Yasuo,

Le Tue, 10 Feb 2015 07:25:00 +0100, Yasuo Ohgaki  a  
écrit:

Updated wiki page.
https://wiki.php.net/rfc/dbc2


While I agree this RFC is going in the right direction, I don't like the  
use of "require" and "return".


They are already used for something completely different, I think it will  
make the code more difficult to understand (for beginners) and parse (for  
external programs). IDE will have some difficulties too. I've discussed  
about it with some PHP developers who work with me, and they all agree.


If it was me, I would use "pre" and "post", "in" and "out" or "requires"  
and "ensures". I understand that creating more keywords isn't something  
pleasant, but it would make the code more readable and logical.


Regards,
Benoit.

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