Re: [PHP-DEV] Design by Contract

[Ivan Enderlin @ Hoa]

On 06/02/15 09:44, Yasuo Ohgaki wrote:

Hi Ivan,

Hi Yasuo :-),


On Fri, Feb 6, 2015 at 4:44 PM, Ivan Enderlin @ Hoa 
ivan.ender...@hoa-project.net mailto:ivan.ender...@hoa-project.net 
wrote:






On Thu, Feb 5, 2015 at 11:25 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net
mailto:ivan.ender...@hoa-project.net wrote:

I just would like to point out some stuff.


tl;dr: Contracts can be used to validate code
(Design-by-Contract) or generate test data to validate code
(Contract-based Testing). There are plenty of contract
languages in the wild, each one addresses a specific problem
(object, structured type, temporal logic, scenario etc.). If
we try to develop a contract language, **IT WILL FAIL**, I
guarantee it. The solution is to give tools to developers to
ease the use of contracts, for example with Aspect Oriented
Programming.


There is a whole research PhD thesis about Contract-based
Testing in PHP, which includes Design-by-Contract, automatic
generation of complex test data and automatic generation of
test suites:
https://dl.dropboxusercontent.com/u/26317193/PhdThesis.pdf.
Unfortunately, the thesis is in French but research articles
are in English. You can found them here
(http://hoa-project.net/En/Literature.html#Research):
  * Praspel: A Specification Language for Contract-Driven
Testing in PHP (article:
http://hoa-project.net/En/Literature/Research/Ictss11.pdf,
keynote: http://keynote.hoa-project.net/Ictss11/EDGB11.pdf),
  * Grammar-Based Testing using Realistic Domains in PHP
(article:
http://hoa-project.net/En/Literature/Research/Amost12.pdf,
keynote: http://keynote.hoa-project.net/Amost12/EDGB12.pdf),
  * A Constraint Solver for PHP Arrays (article:
http://hoa-project.net/En/Literature/Research/Cstva13.pdf,
keynote: http://keynote.hoa-project.net/Cstva13/EGB13.pdf).

Concepts behind contracts are twofold:
  1. Design-by-Contract (DbC), validate code at compile time
or at runtime (in the case of PHP, it will be at runtime),
  2. Contract-based Testing (CbT), generate test data based
on contracts. Preconditions are used to generate inputs, and
postconditions validate outputs. Invariants must hold before
and after the execution of the SUT (System Under Test, here
methods and functions).

So there are two goals with contracts. We can only address
validation (DbC) or both (DbC and CbT).

From my own experience and study in this field (I am a PhD in
the test domain), I suggest you to NOT introduce DbC and CbT
in PHP. Why? Because the language used to express contracts
(even if we use PHP) will be too much poor or too much
inappropriate for test data validation or test data
generation (resp. DbC or CbT).

The articles listed above, in addition to the PhD thesis,
present Praspel, a specification language for PHP, based on
contracts. Praspel is used to validate and generate (test)
data and test suites. This language is inspired from JML
(Java Modeling Language) and ACSL (ANSI/C Specification
Language) while addressing PHP features (weakly type for
instance). But there is a lot more languages in the wild.
Inventing another language will lead to a fail at a
particular time, believe me. Each contract language has a
specificity: Handling structured data, handling events,
handling scenario (see Dwyer patterns for temporal linear
logic) etc. We CANNOT address all these needs.

However, there is a hope :-). DbC and CbT can be easily
implemented with an Aspect Oriented Programming (AOP)
paradigm. Before each “method execution”, we interpret or
execute the invariants and the preconditions expressed in the
contract, the method runs and after “method execution”, we
interpret or execute the invariants and the postconditions
expressed in the contract. No need to have a specific
implementation in PHP's core for contracts.
Moreover, we can enable or disable AOP in development or
production environment, which ensures performances.


It sounds you are looking for way beyond what we discuss.
If there are contracts, program correctness may be proven by
contracts, but
this kind of validation is not in scope.

Proven? I don't dare to speak about proof here. If you would like
to execute pre-, postconditions and invariants at runtime, you
need a super language to define behaviors efficiently… and the
problem is: What behaviors? Only the data type? The order of
execution of methods? The time of execution of methods? A lot of
constraints 

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

[Dmitry Stogov]

This is definitely not a blocker.
Slight degradation is caused by additional checks on each function call.
Anyway, it's an issue that would be geat to fix.

Thanks. Dmitry.

On Mon, Feb 9, 2015 at 11:17 AM, Pierre Joye pierre@gmail.com wrote:

 On Mon, Feb 9, 2015 at 3:04 PM, Dmitry Stogov dmi...@zend.com wrote:
  this is more or less true. :(
  The proposal is presented in an unfair way to include strict typing
 without
  the ability to vote for weak types only.
 
  Despite of semantic arguments, the implementation is a bit immature and
  introduces slowdown for any code without type hints.

 Hm, I have a bad feeling about this argument popping up again now. I
 did not see any significant perf degradation using common apps but I
 ask Matt to run some tests again using the PR vs master, let discuss
 actual subjective numbers instead of raising the performance impact
 blocker :)

 Cheers,
 Pierre

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

Usage of return is a good idea.
The more heads the better result :)

Thanks. Dmitry.

On Mon, Feb 9, 2015 at 11:48 AM, Joe Watkins pthre...@pthreads.org wrote:

 Morning internals,

 I really liked the original idea Dmitry had, with the D-ish syntax.

We could use require and return like:

 function foo()
 require(input-expr)
 return(output-expr) {
 /* ... */
 }

 to avoid adding more keywords.

 I'd really appreciate seeing this as an option in the RFC.

 Cheers
 Joe

 On Mon, Feb 9, 2015 at 8:44 AM, Dmitry Stogov dmi...@zend.com wrote:

 It's nothing wrong here. It's just a concept that cares about constraints
 definition more.

 So, DbC with asserts spread among the code is like OOP without classes.

 Thanks. Dmitry.


 On Mon, Feb 9, 2015 at 2:11 AM, Stanislav Malyshev smalys...@gmail.com
 wrote:

  Hi!
 
   Following our conversation, I tried to imagine how DbC should look
 like
  in
   PHP from user perspective. Finally, I was influenced by the semantic
   proposed in D, and syntax proposed for Java. So, these are my initial
   thoughts:
  
   For php it may look like the following:
  
   function foo()
   requre(input-assert-expression)
   ensure(output-assert-expression)
   {
 ...
   }
 
  Why not do it simpler?
 
  function foo() {
  // require
  assert(input-assert-expression);
  ...
  // ensure
  assert(output-assert-expression);
  }
 
  I'm oversimplifying a bit, but in general, why we need more places to
  have code in the function than the actual code of the function? It would
  be harder to parse, to read, to maintain, to debug, to profile, etc. and
  I'm not sure what exactly it provides that can't be done by plain
  regular code inside the function.
 
  If we're concerned about the costs of assert, we could make special
  provision in the compiler for zero-cost asserts. It doesn't require
  moving code out of the function.
  --
  Stas Malyshev
  smalys...@gmail.com
 

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

Can you suggest what exactly should be done?

Thanks. Dmitry.

On Mon, Feb 9, 2015 at 11:16 AM, Pavel Kouřil pajou...@gmail.com wrote:

 
  There are a lot of researches in this field. PHP has a great opportunity
 to
  not close the doors by forcing a language. I suggest you to offer an API
 to
  hook on the runtime and “control” it, like AOP does. It will open the
 doors
  to so many interesting contributions!
 

 Hello,

 after reading this discussion, this seems like the best way to handle DbC.


 Regards
 Pavel Kouril

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

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

[Benjamin Coutu]

Hello everyone,

(Un)fortunately I do not have voting rights, but here is my (freely expressed) 
50 cents anyways:

I appreciate that Andrea is trying to come up with a one-size-fits-all RFC. 
Nevertheless I believe it is flawed in regards to content as well as formally 
in terms of voting options.

In my view this has become a fight over feature request vs. language 
consistency. I understand that a large part of userland is or would be in favor 
of this RFC - they always prefer new features as long as they are backward 
compatible. You might as well introduce an (configuration/declare) option for 
static typing, and userland would probably cheer. This does not necessarily 
make it a good thing though.

You, @internals, are the guardians of this language and should consider 
intrinsic language consistency as a paramount objective. At the end of the day 
PHP is fundamentally a weakly typed language. Introducing an optionality in how 
the fundamental semantics of the language work (with the declare-proposal) is 
not well thought trough. It is by all means quite hacky - reminds me of 
register-globals, mb-function-overloading, etc. - everything bad about PHP. As 
we all know bad things cannot be revoked easily once introduced.

This doesn't mean strict type hinting cannot be done in a coherent way. There 
have been good (or at least compatible) proposals, e.g. seeing (type) as a 
weak hint and type as a strict hint. This would be somewhat consistent with 
both, casting expressions as well as the existing strict/strong type hints for 
objects. But maybe having both is not the right (PHP) way after all. The only 
thing 100% consistent with the current language semantics would be no type 
hinting at all or some form of weak type hinting. Everything else would be nice 
to have, if (and only if) done right.

Ultimately, and I am sorry to say that, I think this discussion is symptomatic 
for the lack of professionalism among the PHP community, keeping many potential 
contributors (like my colleagues and myself) from actually committing resources 
apart from mere observation. I find it very discouraging that well argued 
opinions of lead developers of this project, such as Andi, Rasmus and Zeev, are 
dismissed so bluntly. I do not recall any instance in the PostgreSQL community 
where Tom Lane or some other senior contributor has been so harshly treated. 
Having the original designers of the language keenly reject this proposal 
should be a concern to all of us, independently of subjective opinion or the 
current voting result.

The honorable (and rational) thing to do would be for the author to retract 
this RFC and thereby postpone the decision (I am aware that the feature freeze 
looms!). This is so important for the future of PHP, so let's don't rush it, 
but try to do it right!

Cheers,

Ben

== Original ==
From: Matthew Leverton lever...@gmail.com
To: Zeev Suraski z...@zend.com
Date: Mon, 09 Feb 2015 05:20:25 +0100
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints



On Sun, Feb 8, 2015 at 3:22 PM, Zeev Suraski z...@zend.com wrote:
 I'm well aware of it as I wrote that policy.  The goal of the policy was to
 prevent a situation where a temporary majority can introduce features into
 the language that would later on be impossible to reverse.  It's not by any
 stretch a good mechanism to solve controversial votes, which again, should
 ideally be avoided as much as possible.  It's just that there isn't a better
 mechanism.

I know I'm unfairly paraphrasing you, but it sounds like you are
saying that for things that you don't have strong feelings about, then
you're fine if the others vote amongst themselves. But for things that
matter to you, you want to reserve the right to prevent change. Is
there a way to fairly describe what you consider too controversial to
vote on?

The problem I see with votes for this type of feature is that you
probably have a breakdown of something like:

- 10% of people don't want scalar type hints
- 20% of people want both, but 50% of them would vote for either weak or strong
- 35% of people want strict, but 80% of them are fine with weak
- 35% of people want weak, but 80% of them are fine with strong

So if a strict-only vote happens first, you get 73% to say yes. If
weak-only vote happens first, you get 73% to say yes.

(I'm obviously just making up these numbers with no scientific basis,
but I think the principle is valid.)

The only way to be fair IMO is to hold a vote where you rank those
four options (weak, strong, both, neither) and hold an instant run-off
vote where the first majority wins. And if 'neither' wins, then agree
that the topic cannot be revisited until next major version, so that
everybody can rest for 5 years. ;)

--
Matthew Leverton


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

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

Morning internals,

I really liked the original idea Dmitry had, with the D-ish syntax.

   We could use require and return like:

function foo()
require(input-expr)
return(output-expr) {
/* ... */
}

to avoid adding more keywords.

I'd really appreciate seeing this as an option in the RFC.

Cheers
Joe

On Mon, Feb 9, 2015 at 8:44 AM, Dmitry Stogov dmi...@zend.com wrote:

 It's nothing wrong here. It's just a concept that cares about constraints
 definition more.

 So, DbC with asserts spread among the code is like OOP without classes.

 Thanks. Dmitry.


 On Mon, Feb 9, 2015 at 2:11 AM, Stanislav Malyshev smalys...@gmail.com
 wrote:

  Hi!
 
   Following our conversation, I tried to imagine how DbC should look like
  in
   PHP from user perspective. Finally, I was influenced by the semantic
   proposed in D, and syntax proposed for Java. So, these are my initial
   thoughts:
  
   For php it may look like the following:
  
   function foo()
   requre(input-assert-expression)
   ensure(output-assert-expression)
   {
 ...
   }
 
  Why not do it simpler?
 
  function foo() {
  // require
  assert(input-assert-expression);
  ...
  // ensure
  assert(output-assert-expression);
  }
 
  I'm oversimplifying a bit, but in general, why we need more places to
  have code in the function than the actual code of the function? It would
  be harder to parse, to read, to maintain, to debug, to profile, etc. and
  I'm not sure what exactly it provides that can't be done by plain
  regular code inside the function.
 
  If we're concerned about the costs of assert, we could make special
  provision in the compiler for zero-cost asserts. It doesn't require
  moving code out of the function.
  --
  Stas Malyshev
  smalys...@gmail.com
 

Re: [PHP-DEV] new json, push generated file?

[Anatol Belski]

Hi,

On Mon, February 9, 2015 07:33, Xinchen Hui wrote:
 Hey:




 On Mon, Feb 9, 2015 at 1:44 PM, Pierre Joye pierre@gmail.com wrote:

 On Mon, Feb 9, 2015 at 11:10 AM, Xinchen Hui larue...@php.net wrote:

 Hey:


 On Mon, Feb 9, 2015 at 10:40 AM, Pierre Joye pierre@gmail.com
 wrote:

 hi,

 Should we push json_parser.tab.c? Which is generated (re2c), just
 like what is done in date or other?

 I think we should, and also use a better name...(.tab.c?)


 that too :)
 simply, json_parser.c is good

 something like: https://gist.github.com/laruence/f33903266cec737088aa

I'd be for applying this as well. Also, just added the generation calls to
config.w32, but actulaly a checked in file were much simpler to handle.

Regards

Anatol



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

Re: [PHP-DEV] new json, push generated file?

[Jakub Zelenka]

On Mon, Feb 9, 2015 at 9:18 AM, Anatol Belski anatol@belski.net wrote:

 Hi,

 On Mon, February 9, 2015 07:33, Xinchen Hui wrote:
  Hey:
 
 
 
 
  On Mon, Feb 9, 2015 at 1:44 PM, Pierre Joye pierre@gmail.com
 wrote:
 
  On Mon, Feb 9, 2015 at 11:10 AM, Xinchen Hui larue...@php.net wrote:
 
  Hey:
 
 
  On Mon, Feb 9, 2015 at 10:40 AM, Pierre Joye pierre@gmail.com
  wrote:
 
  hi,
 
  Should we push json_parser.tab.c? Which is generated (re2c), just
  like what is done in date or other?
 
  I think we should, and also use a better name...(.tab.c?)
 
 
  that too :)
  simply, json_parser.c is good
 
  something like: https://gist.github.com/laruence/f33903266cec737088aa
 
 I'd be for applying this as well. Also, just added the generation calls to
 config.w32, but actulaly a checked in file were much simpler to handle.

 Regards

 Anatol


Hi,

The re2c generated files are pushed (see
https://github.com/php/php-src/blob/master/ext/json/json_scanner.c ). The
json_parser.tab.c is a BISON generated file. I haven't pushed that file
because we don't have bison generated files in repo (e.g.
zend_language_parser.c). I'm actually for pushing that file as well but
then we should probably push zend_language_parser.c too. Thoughts?

The name .tab.c is a standard name for bison files ( see last paragraph
http://www.gnu.org/software/bison/manual/html_node/Rpcalc-Generate.html#Rpcalc-Generate
). I think that it can be changed but not sure if it makes much sense. The
.tab.c says that it's a C file with parsing tables...

Cheers

Jakub

Re: [PHP-DEV] Dragging the legacy users forward.

[Tony Marston]

Matteo Beccati  wrote in message news:54d74c68.6070...@beccati.com...


On 08/02/2015 11:24, Tony Marston wrote:

Well said. If it is not possible to have a single codebase that runs in
both PHP 5 *AND* PHP 7 then that will be a total disaster.


Of course you can have a single codebase running both on PHP5 and PHP7, 
unless you want to use PHP7-only features.


But that doesn't mean that any codebase that currently runs on PHP5 will 
keep working on PHP7 without any changes. Most of the modern codebases 
probably will though.


But there is a vociferous group who want to change the language in a 
revolutionary way instead of an evolutionary way. They want to drop weak 
typing and replace it with strict typing, they want to replace a lot of 
function names with something more consistent, and they want PHP to have a 
purer OO model so that instead of string = strtoupper($string) you must 
use $string-toUpper. These revolutionaries want PHP 7 to be a different 
language, not an extension of the existing PHP 5 version.


--
Tony Marston


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

Re: [PHP-DEV] Dragging the legacy users forward.

[Matteo Beccati]

On 09/02/2015 10:49, Tony Marston wrote:

But there is a vociferous group who want to change the language in a
revolutionary way instead of an evolutionary way. They want to drop weak
typing and replace it with strict typing, they want to replace a lot of
function names with something more consistent, and they want PHP to
have a purer OO model so that instead of string =
strtoupper($string) you must use $string-toUpper. These
revolutionaries want PHP 7 to be a different language, not an extension
of the existing PHP 5 version.


I don't see any such RFC for PHP7. So it's probably worth if we avoid 
complaining about something that's not being proposed and certainly not 
going to happen.



Cheers
--
Matteo Beccati

Development  Consulting - http://www.beccati.com/

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

RE: [PHP-DEV] [VOTE] Scalar Type Hints

[Zeev Suraski]

 -Original Message-
 From: Andrea Faulds [mailto:a...@ajf.me]
 Sent: Monday, February 09, 2015 12:44 PM
 To: Zeev Suraski
 Cc: Jordi Boggiano; internals@lists.php.net
 Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints

 Hi,

  On 9 Feb 2015, at 03:48, Zeev Suraski z...@zend.com wrote:
 
  A - has pretty much everybody agreeing with is a good idea.  Nobody
 objects to it.  It's under consensus.

 This isn't true. I've explained why it isn't true several times. Maybe
you are
 suffering from confirmation bias or something, but there is no such
 consensus. Quite a few internals contributors liked v0.1. Quite a few
didn't.
 I've gone and evidenced this before in replies sent directly to you.

Andrea,

I'll make an absolute last attempt to explain what I'm saying, after that
we can agree to disagree.  We probably interpret the same facts
differently.

Fact is, there were very few people who said that weak types are *bad*
(although Sebastian seems to fall in that category).  The vast majority of
feedback that 'opposed' weak typing, didn't really oppose weak typing at
all.  What it opposed was, rather, the lack of introducing strict typing.
That is clearly not the same thing, which is why the fact there were
people who opposed v0.1 of the RFC does not equate with people opposing
weak typing, not at all.

Each and every person that voted in favor of the v0.3 RFC, voted in favor
of weak typing.  Weak typing is not only a key element of that RFC - it's
even the default behavior.  In addition to everyone who voted in favor of
the v0.3 RFC, many - most probably most of the people who voted against
it- are in favor of the weak typing API.  If you combine the two groups,
you're going to get to nearly 100% support, or arguably, 'lack of
opposition', to the weak typing proposal.

So I stand by my comment, which has nothing to do with confirmation bias
but is based on simple facts, that there's consensus (or near consensus)
about weak typing being acceptable into the language.   Of course, many of
the people in the strict typing camp are not actively supportive of the
weak typing part, but they also don't oppose it.  Again, the fact they
voted in favor of adding them attests to that.

The controversy is exclusively around strict typing.  It goes both ways -
proponents of strict typing feel very passionate about having to introduce
it into the language;  Opponents seem to feel equally passionate about not
adding them.

I hope that clarifies my previous statements and put that part of the
discussion to rest.

Zeev

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

Re: [PHP-DEV] Annotated PHP 5-7 extension diff

[Jan Ehrhardt]

Dan Ackroyd in php.internals (Fri, 6 Feb 2015 16:16:09 +):
On 5 February 2015 at 22:28, Rasmus Lerdorf ras...@lerdorf.com wrote:
 Any suggestions for how to handle annotating it? We could turn it into a
 fake PR and mark it up using github's PR comments.
(...)
An incomplete checklist for migrating an extension to PHP7
--
[snip]

Despite the extensive list of changes, imagick does not compile anymore
with the current PHP7 git head (Win32 VC11).

Jan

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

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

[Matteo Beccati]

On 09/02/2015 15:50, Pierre Joye wrote:

On Feb 9, 2015 8:52 PM, Sebastian Bergmann sebast...@php.net wrote:

  then the corresponding check must be strict. But since that strictness
  does not align with the spirit of PHP I much rather have no support
  for scalars than one that is not strict.


Not strict? You loose me here.


I guess he meant:  no support for scalar type hints than one that is 
not strict.



Cheers
--
Matteo Beccati

Development  Consulting - http://www.beccati.com/

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

RE: [PHP-DEV] [VOTE] Scalar Type Hints

[Pierre Joye]

On Feb 10, 2015 12:03 AM, Zeev Suraski z...@zend.com wrote:

  -Original Message-
  From: Andrea Faulds [mailto:a...@ajf.me]
  Sent: Monday, February 09, 2015 12:44 PM
  To: Zeev Suraski
  Cc: Jordi Boggiano; internals@lists.php.net
  Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
 
  Hi,
 
   On 9 Feb 2015, at 03:48, Zeev Suraski z...@zend.com wrote:
  
   A - has pretty much everybody agreeing with is a good idea.  Nobody
  objects to it.  It's under consensus.
 
  This isn't true. I've explained why it isn't true several times. Maybe
 you are
  suffering from confirmation bias or something, but there is no such
  consensus. Quite a few internals contributors liked v0.1. Quite a few
 didn't.
  I've gone and evidenced this before in replies sent directly to you.

 Andrea,

 I'll make an absolute last attempt to explain what I'm saying, after that
 we can agree to disagree.  We probably interpret the same facts
 differently.

 Fact is, there were very few people who said that weak types are *bad*
 (although Sebastian seems to fall in that category).  The vast majority of
 feedback that 'opposed' weak typing, didn't really oppose weak typing at
 all.

Oh wait. So the waste majority actually willing this RFC actually want
another? This is fantastic

Anyway, no worry, opposed ppl managed to get this amazing RFC shot down.
Prepare your own to do exactly what you want, how you want, many will
accept it as default choice despite it being a poor choice. A deja vu
feeling is popping up in my mind. Well played.

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

Morning,

A good start ... ish ...

Please steer clear of using the assert API, and in so doing avoid BC
concerns with the current assert API.

Please avoid adding a magic method and use the suggested syntax for
invariant.

class Some {
require(invariant-expr);

/* ... */
}

like that is best I think ...

You need to explain how invariants are going to be inherited and executed
in detail.

Keep statements such as

 With proper use of DbC concept, it is known *programs to be more robust,
secure and faster*

Out of the RFC, since that cannot possibly be true and is just going to
cause people to argue about that point when it's extremely unimportant.

Cheers
Joe

On Mon, Feb 9, 2015 at 11:47 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi all,

 On Tue, Feb 10, 2015 at 5:27 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 On Tue, Feb 10, 2015 at 5:19 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Use of interface:
   - no additional keyword (pros)
   - requires interface for DbC, most classes does not require interface
 (cons)
   - if interface is not used, user has to repeat invariant conditions
 over and over (cons)
   - requires to define method that should not exist in production (cons)

 New keyword:
   - does not require interface for efficient definition (pros).
   - new keyword (cons)

 It seems we are better to choose proper keyword for 'invariant'.
 'invariant' is not common, so 'invariant'
 may be good enough choice. Does anyone use 'invariant' as
 function/method/class/constant names?
 If there is better name, suggestion is appreciated.


 It might be be better to use special method. No keyword, use only
 reserved method name __func().
 I'll write what I think that are better for PHP in the RFC.
 We may discuss anything here to complete the RFC.


 The RFC draft is ready.
 https://wiki.php.net/rfc/dbc2

 I think we might be better to use

 return($ret) {
   assert($ret  0);
 }

 as the syntax. It doesn't look like definition, but code though.

 We may introduce $ or like as return value, but it looks like PERL.
 It's not for me, but PHP stands for People Hate Perl for some.

 Any comments, corrections, improvements are appreciated.
 If anyone could fix bad English, it would be great!

 Regards,

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

Re: [PHP-DEV] Design by Contract

[Patrick Schaaf]

Am 10.02.2015 07:25 schrieb Yasuo Ohgaki yohg...@ohgaki.net:

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

First of all, thanks for your effort so far.

Some questions, after reading the RFC, with no particular order:

1) Regarding invariants: those will be called for method calls on objects.
What about static class methods? Could we have static class invariants
(static require(.))? Would these be called for both static and
nonstatic method calls (nonstatic method calls can change static class
state, too)

2) the pre- and postconditions could be useful for ordinary, non-OO
functions, too, to check parameters, return, and global state invariants

3) I think that method preconditions are not sufficient. Pretty often,
public methods first sanitize and validate their input parameters, and
rightly so. In these cases, it would be useful to have the checking, in the
same general framework, at an arbitrary point in the function body. In
other words, assert (with an expression as the first argument, instead of a
string).

4) regarding the error message second argument to the condition
definitions, it would be useful to have these not only as plain
(extrapolated) strings, but as full expressions-that-evaluate-to-string.
That would permit hooking to arbitrary private logging and log formatting
methods.

5) and a bit off-topic, it would be useful to be able to declare (sic)
whole methods to be nonproduction only: Methods that will only be used in
pre/post/invariant condition expresions (or error formatters a la my point
4)

best regards
  Patrick

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Joe,

On Tue, Feb 10, 2015 at 3:59 PM, Joe Watkins pthre...@pthreads.org wrote:

 I'm not sure we can always enforce invariant contracts ...

 Evaluating invariant expressions on entry and exit is not enough, since a
 property can be changed without the use of a method.

 Can or should, we do anything about that ?

 This should also be covered in the RFC, I think.


One reason I would like to use __invariant() is to allow overriding parents.
I think we should have way for it, but I don't have good idea now.
I'm still thinking.

Regards,

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

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Dmitry,

On Tue, Feb 10, 2015 at 1:43 PM, Dmitry Stogov dmi...@zend.com wrote:

 On Feb 9, 2015 11:20 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 
  Hi Dmitry and Joe,
 
  On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov dmi...@zend.com wrote:
 
  yes. this may work.
  probably better to put it after extends and implements.
 
 
  Dmitry.
 
  On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins pthre...@pthreads.org
 wrote:
 
  Could this be described as a requirement of the class ?
 
  class Mine
  require(invariant-expr)
  extends Something
  implements Someface {
 
  public function method($param) : return
  require(input-expr),
  return(output-expr) {
 
  }
  }
 
  To avoid invariant keyword maybe.
 
 
  This would work.
  If users have adopted DbC in some way, 'invariant' may be used already.
 
  I see two issues.
 
  Interface works, but most classes are class without interfaces. Then
 users have to repeat
  require()/return() many times to check class state or have to use
 interface for DbC.
 

 In D classes may have invariant constraints. We may use require
 keyword for it. The constraints ineritance rules and order of calls to
 constrains must be the same s in D.

 class Foo {
 private $sum = 0;
 require($this-sum = 0); // invariant constraint will be called
 before and after every method
 function add($n) {
  $this-sum += $n;
 }
 }


OK. I'll update the RFC.


  Since compiler does not know a method() is for DbC invariant, it will be
 compiled and exists
  in production execution.
 
  Use of interface:
- no additional keyword (pros)
- requires interface for DbC, most classes does not require interface
 (cons)
- if interface is not used, user has to repeat invariant conditions
 over and over (cons)
- requires to define method that should not exist in production (cons)

 I didn't understand you idea.


Joe's idea was to use Interface for invariant condition grouping.
If we use your idea, issue is solved.

class Foo {
 private $sum = 0;
 require($this-sum = 0); // invariant constraint will be called
 before and after every method
 function add($n) {
  $this-sum += $n;
 }
 }

Ok.

 
  New keyword:
- does not require interface for efficient definition (pros).
- new keyword (cons)
 
  It seems we are better to choose proper keyword for 'invariant'.
 'invariant' is not common, so 'invariant'
  may be good enough choice. Does anyone use 'invariant' as
 function/method/class/constant names?
  If there is better name, suggestion is appreciated.
 
  On place closure call like javascript is not supported in PHP, but
 function works with assert.
 
  ?php
  function foo() { return FALSE; }
  assert(foo());
  ?
  PHP Warning:  assert(): Assertion failed in - on line 3
 
  This wouldn't be changed for require()/return()/invariant()?
 
  We need a switch to change development/production. I'll use dbc=On/Off
 for now.
  If you have any better idea, please let me know. (dbc will be INI_SYSTEM)

 Check the expectations RFC. I think, it's going to be 3 state switch,
 zero-cost disable, run-time disable, run-time enable. So, it may be
 INI_ALL, but it won't be possible to switch from/to zero-cost at run-time.


Ok.

 
  For CLI, there will be no command line switch for dbc. It executes
 script production mode by
  default. If user needs development mode
 
  php -d dbc=1 script.php
 
  should be used.
 
 
  And finally, are we going to allow custom assertion error message? e.g.
 
  require($a  0, 'Parameter $a must be positive number');

 I think, it may be useful.

Ok. I'll use it.

 
  Since this contract is definition like implements/extends, we may
 not allow
  custom error message. I'll write the RFC not to allow custom error
 messages unless
  you dislike it.
 
  I think we have enough consensus/information to start writing the RFC.
  If I have any concern, I'll ask here.

 Ok, go forward :)

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

If you would like to change something, please let me know.
I don't think finished draft at all and I don't mind going back and forth.

Regards,

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

Re: [PHP-DEV] new json, push generated file?

[Xinchen Hui]

Hey:

On Tue, Feb 10, 2015 at 3:19 AM, Jakub Zelenka bu...@php.net wrote:
 On Mon, Feb 9, 2015 at 1:55 PM, Pierre Joye pierre@gmail.com wrote:

 I still think it is better to have this file applied. It is not like they
 will change every 2nd day.

 Hi,

 I think that I might have solution for this and also for my another build
 problem which is re2c version.

 I have just created a PR where I tried to explain everything:

 https://github.com/php/php-src/pull/1072

 Basically ti adds all sources but allows to regenerate them only if the
 options --enable-json-filegen is set (more details are in the description).

 The config changes are just for Linux as I'm not sure how to do it on win
 and if it's even needed (if someone will send any patches to json scanner or
 parser and needs to generate them automatically).

 I'll keep the PR open for a week or so and if there are no objection, I
 would like merge it. I'm also open changing the name of the option and will
 be glad for any config.m4 related comments and reviews.
why make this thing in this way complicated? why not just simply
include the generated files as others did?

thanks

 Cheers

 Jakub




-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] new json, push generated file?

[Pierre Joye]

On Tue, Feb 10, 2015 at 9:47 AM, Xinchen Hui larue...@php.net wrote:

 why make this thing in this way complicated? why not just simply
 include the generated files as others did?

There are cases where it is configure dependent so not including them
makes sense.

I do not recognize this case with json.


-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

 Joe's idea was to use Interface for invariant condition grouping.

It wasn't, it was to use require at the class declaration, using it in
the class body is better still ...

Cheers
Joe

On Tue, Feb 10, 2015 at 6:27 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Joe,

 On Tue, Feb 10, 2015 at 3:16 PM, Joe Watkins pthre...@pthreads.org
 wrote:

 You need to explain how invariants are going to be inherited and executed
 in detail.


 OK. Thank you. This wouldn't change even if syntax changes.



 Keep statements such as

  With proper use of DbC concept, it is known *programs to be more
 robust, secure and faster*

 Out of the RFC, since that cannot possibly be true and is just going to
 cause people to argue about that point when it's extremely unimportant.


 Good point.

 Regards,

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

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

I'm not sure we can always enforce invariant contracts ...

Evaluating invariant expressions on entry and exit is not enough, since a
property can be changed without the use of a method.

Can or should, we do anything about that ?

This should also be covered in the RFC, I think.

Cheers
Joe

On Tue, Feb 10, 2015 at 6:49 AM, Dmitry Stogov dmi...@zend.com wrote:

 Hi,

 can I make some minor correction?

 Thanks. Dmitry.



 On Tue, Feb 10, 2015 at 9:25 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Dmitry,

 On Tue, Feb 10, 2015 at 1:43 PM, Dmitry Stogov dmi...@zend.com wrote:

 On Feb 9, 2015 11:20 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 
  Hi Dmitry and Joe,
 
  On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov dmi...@zend.com wrote:
 
  yes. this may work.
  probably better to put it after extends and implements.
 
 
  Dmitry.
 
  On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins pthre...@pthreads.org
 wrote:
 
  Could this be described as a requirement of the class ?
 
  class Mine
  require(invariant-expr)
  extends Something
  implements Someface {
 
  public function method($param) : return
  require(input-expr),
  return(output-expr) {
 
  }
  }
 
  To avoid invariant keyword maybe.
 
 
  This would work.
  If users have adopted DbC in some way, 'invariant' may be used already.
 
  I see two issues.
 
  Interface works, but most classes are class without interfaces. Then
 users have to repeat
  require()/return() many times to check class state or have to use
 interface for DbC.
 

 In D classes may have invariant constraints. We may use require
 keyword for it. The constraints ineritance rules and order of calls to
 constrains must be the same s in D.

 class Foo {
 private $sum = 0;
 require($this-sum = 0); // invariant constraint will be called
 before and after every method
 function add($n) {
  $this-sum += $n;
 }
 }


 OK. I'll update the RFC.


  Since compiler does not know a method() is for DbC invariant, it will
 be compiled and exists
  in production execution.
 
  Use of interface:
- no additional keyword (pros)
- requires interface for DbC, most classes does not require
 interface (cons)
- if interface is not used, user has to repeat invariant conditions
 over and over (cons)
- requires to define method that should not exist in production
 (cons)

 I didn't understand you idea.


 Joe's idea was to use Interface for invariant condition grouping.
 If we use your idea, issue is solved.

 class Foo {
 private $sum = 0;
 require($this-sum = 0); // invariant constraint will be called
 before and after every method
 function add($n) {
  $this-sum += $n;
 }
 }

 Ok.

 
  New keyword:
- does not require interface for efficient definition (pros).
- new keyword (cons)
 
  It seems we are better to choose proper keyword for 'invariant'.
 'invariant' is not common, so 'invariant'
  may be good enough choice. Does anyone use 'invariant' as
 function/method/class/constant names?
  If there is better name, suggestion is appreciated.
 
  On place closure call like javascript is not supported in PHP, but
 function works with assert.
 
  ?php
  function foo() { return FALSE; }
  assert(foo());
  ?
  PHP Warning:  assert(): Assertion failed in - on line 3
 
  This wouldn't be changed for require()/return()/invariant()?
 
  We need a switch to change development/production. I'll use
 dbc=On/Off for now.
  If you have any better idea, please let me know. (dbc will be
 INI_SYSTEM)

 Check the expectations RFC. I think, it's going to be 3 state switch,
 zero-cost disable, run-time disable, run-time enable. So, it may be
 INI_ALL, but it won't be possible to switch from/to zero-cost at run-time.


 Ok.

 
  For CLI, there will be no command line switch for dbc. It executes
 script production mode by
  default. If user needs development mode
 
  php -d dbc=1 script.php
 
  should be used.
 
 
  And finally, are we going to allow custom assertion error message? e.g.
 
  require($a  0, 'Parameter $a must be positive number');

 I think, it may be useful.

 Ok. I'll use it.

 
  Since this contract is definition like implements/extends, we may
 not allow
  custom error message. I'll write the RFC not to allow custom error
 messages unless
  you dislike it.
 
  I think we have enough consensus/information to start writing the RFC.
  If I have any concern, I'll ask here.

 Ok, go forward :)

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

 If you would like to change something, please let me know.
 I don't think finished draft at all and I don't mind going back and forth.

 Regards,

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

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

good point, but I think we can do nothing about that.
Anyway, it should be reflected in RFC.

Dmitry.



On Tue, Feb 10, 2015 at 9:59 AM, Joe Watkins pthre...@pthreads.org wrote:

 I'm not sure we can always enforce invariant contracts ...

 Evaluating invariant expressions on entry and exit is not enough, since a
 property can be changed without the use of a method.

 Can or should, we do anything about that ?

 This should also be covered in the RFC, I think.

 Cheers
 Joe

 On Tue, Feb 10, 2015 at 6:49 AM, Dmitry Stogov dmi...@zend.com wrote:

 Hi,

 can I make some minor correction?

 Thanks. Dmitry.



 On Tue, Feb 10, 2015 at 9:25 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Dmitry,

 On Tue, Feb 10, 2015 at 1:43 PM, Dmitry Stogov dmi...@zend.com wrote:

 On Feb 9, 2015 11:20 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 
  Hi Dmitry and Joe,
 
  On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov dmi...@zend.com
 wrote:
 
  yes. this may work.
  probably better to put it after extends and implements.
 
 
  Dmitry.
 
  On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins pthre...@pthreads.org
 wrote:
 
  Could this be described as a requirement of the class ?
 
  class Mine
  require(invariant-expr)
  extends Something
  implements Someface {
 
  public function method($param) : return
  require(input-expr),
  return(output-expr) {
 
  }
  }
 
  To avoid invariant keyword maybe.
 
 
  This would work.
  If users have adopted DbC in some way, 'invariant' may be used
 already.
 
  I see two issues.
 
  Interface works, but most classes are class without interfaces. Then
 users have to repeat
  require()/return() many times to check class state or have to use
 interface for DbC.
 

 In D classes may have invariant constraints. We may use require
 keyword for it. The constraints ineritance rules and order of calls to
 constrains must be the same s in D.

 class Foo {
 private $sum = 0;
 require($this-sum = 0); // invariant constraint will be called
 before and after every method
 function add($n) {
  $this-sum += $n;
 }
 }


 OK. I'll update the RFC.


  Since compiler does not know a method() is for DbC invariant, it will
 be compiled and exists
  in production execution.
 
  Use of interface:
- no additional keyword (pros)
- requires interface for DbC, most classes does not require
 interface (cons)
- if interface is not used, user has to repeat invariant conditions
 over and over (cons)
- requires to define method that should not exist in production
 (cons)

 I didn't understand you idea.


 Joe's idea was to use Interface for invariant condition grouping.
 If we use your idea, issue is solved.

 class Foo {
 private $sum = 0;
 require($this-sum = 0); // invariant constraint will be called
 before and after every method
 function add($n) {
  $this-sum += $n;
 }
 }

 Ok.

 
  New keyword:
- does not require interface for efficient definition (pros).
- new keyword (cons)
 
  It seems we are better to choose proper keyword for 'invariant'.
 'invariant' is not common, so 'invariant'
  may be good enough choice. Does anyone use 'invariant' as
 function/method/class/constant names?
  If there is better name, suggestion is appreciated.
 
  On place closure call like javascript is not supported in PHP, but
 function works with assert.
 
  ?php
  function foo() { return FALSE; }
  assert(foo());
  ?
  PHP Warning:  assert(): Assertion failed in - on line 3
 
  This wouldn't be changed for require()/return()/invariant()?
 
  We need a switch to change development/production. I'll use
 dbc=On/Off for now.
  If you have any better idea, please let me know. (dbc will be
 INI_SYSTEM)

 Check the expectations RFC. I think, it's going to be 3 state switch,
 zero-cost disable, run-time disable, run-time enable. So, it may be
 INI_ALL, but it won't be possible to switch from/to zero-cost at run-time.


 Ok.

 
  For CLI, there will be no command line switch for dbc. It executes
 script production mode by
  default. If user needs development mode
 
  php -d dbc=1 script.php
 
  should be used.
 
 
  And finally, are we going to allow custom assertion error message?
 e.g.
 
  require($a  0, 'Parameter $a must be positive number');

 I think, it may be useful.

 Ok. I'll use it.

 
  Since this contract is definition like implements/extends, we may
 not allow
  custom error message. I'll write the RFC not to allow custom error
 messages unless
  you dislike it.
 
  I think we have enough consensus/information to start writing the RFC.
  If I have any concern, I'll ask here.

 Ok, go forward :)

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

 If you would like to change something, please let me know.
 I don't think finished draft at all and I don't mind going back and
 forth.

 Regards,

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

Re: [PHP-DEV] Remove mycrypt. Vote ends Monday

[Tom Worster]

On 2/8/15, 6:23 PM, Stanislav Malyshev smalys...@gmail.com wrote:

The better alternative you proposing is having no mcrypt extension at
all in core. Which means the users have three choices:

1. Rewrite all their code to a different API (with accompanying costs in
development, QA, stability, maintenance of code base now having two
APIs, etc.)
2. Do not upgrade to PHP 7
3. Use the same extension from PECL

Option 1 however is very expensive, so it is unlikely most of the users
will choose it.

Both options 2 and 3 make the security situation for an average user
worse, as not upgrading means eventually falling out of supported
versions - and we're doing *very bad* in this regard, over 46% of the
users run EOLed versions now and less than 1% run current stable - and
running PECL one means most core devs will pay next to zero attention to
it.

As a PHP user, I have no interest in running the latest release. I'll
stay on 5.5 until the next LTS is mature. I know a lot of PHP users who
have a similar attitude: it is sufficient to be on a supported version.
People are scared of the bleeding edge and I think that goes a long way
to explaining the 1%.

Trying to improve these numbers by bringing along a crypto lib that's
been abandoned 8 years ago just doesn't strike me as either justified
or plausible. mcrypt is not the difference that makes conservatives like
me jump onto the latest release. Nor is it going to help the 43%, which,
I imagine, represents apps that aren't ever going to see further
development and lazy hosting.

I also disagree with your analysis. There is simply no hurry to get onto
PHP 7, so I have time to get rid of mycrypt, something I must do ASAP
regardless whether it is in PHP 7 or not.

In any case, I'll stop discussing this now. The vote outcome won't
change in the next 6.5 hours.

Tom



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

Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions

[Pascal MARTIN, AFUP]

Le 02/02/2015 20:11, Anatol Belski a écrit :

https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.


Hi,

After discussing this RFC with other people at AFUP (we weren't that 
many to participate in this discussion -- which probably indicates not 
many of us care about keeping those), it seems we would be:


 * +1 to remove all SAPIs listed in this RFC
 * +1 to remove ext/imap and ext/mcrypt -- some of us would have 
preferred keeping those, but a new major version feels like the right 
time to drop them, if the underlying libraries aren't maintained anymore.

 * +1 to remove ext/mssql and ext/sybase_ct
 * and +0 for ext/pdo_dblib -- we didn't reach a consensus on that one.

Thanks

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/

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

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

[Lars Strojny]

Hi Matteo,

sorry for the late response.

 On 07 Feb 2015, at 12:46, Matteo Beccati p...@beccati.com wrote:
 
 Maybe it's just me, but I didn't quite understand the point you are making 
 here. Are you saying that declares are more or less like ini settings?

Yes, exactly that. The new declare()-statement will fundamentally change how 
the engine behaves and one will have two learn more or less two flavors of PHP. 
Even worse I am forced to use the PHP flavor the person picked who changed the 
declare() statement last.

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[André Rømcke]

On 09 Feb 2015, at 19:24 , guilhermebla...@gmail.com wrote:
 
 Hi Andrea,
 
 I totally see your viewpoint. That's why initially I voted YES, because
 your proposal somehow makes sense.
 My when I thought over and use a weak/strict boolean type conversion on my
 own brain, I came to the conclusion my real wish does not get fully
 addressed with a YES, leading me to switch my vote.
 I really wanted to expose the motivation of my change here, so everyone is
 aware that I do love strict typing, and I really want this in for PHP, but
 not in this RFC way.


To me this is the best compromise that can be made here.
In case of boolean: if you specify boolean, boolean is what you get, no matter 
what user of your library do.

So you are in full control here!
You are not, however, in control over other peoples code, which you shouldn’t 
be anyway. After all you didn’t write it.

The RFC quite elegantly allows both strict and weak camps to be pleased, 
bikeshedding on declare() aside.
So it is a pity people in those camps don’t see that, as this is rather 
overdue* feature.


Best,
André


* It is a feature that allows us all to write more reliable, shorter, and 
better self documented code.
  We got it for all other types up until now, only scalars missing.

[PHP-DEV] Design by Contract and scalar types ...

[Lester Caine]

May as well do something practical while I am testing ...

http://php7.lsces.org.uk/wiki/view/The+good+old+days+...+annotation+without+overheads

First thing to pick up ... PHP7 is a good 20% faster than the current
PHP5.6.5 but I'm seeing no speed difference between 5.6.5 and 5.4.20, so
as long as can leapfrog the remaining PHP5.x builds then all of the time
upgrading TO 5.4 is not a waste.

But the main reason for posting this was the recent comments that strict
types has nothing to do with annotation. It was EVERYTHING to do with
annotation and project design. Every value I pass to the verify function
has to be validated for much more than just integer or string, so how do
I pass the correct information for this single function.

content_id would have been a 32bit integer in the 90's, but the upgrade
of SQL sequences to 64bit has changed that. user id's are still 32bit
integers, and create and edit are timestamps which are another
contentious area when trying to work cross database. Mine are 32bit day
+ 32bit time, so a pair of current integers, but stored as a 64bit value
in the database. title is a 250 character string, and while ip is v4 at
present v6 needs to be catered for in PHP7. I see nowhere here that a
few limited strict tags provides any help, but every value passed
currently will need additional code if the integer checking becomes an
unconstrained object.

Much has been made of adding a class string to handle all the extra
unicode processing, but I am now thinking that a properly exposed string
and integer class which has the ability to assign constraint checks does
make sense. Then use of an integer value on a 32bit platform can error
when the actual value is too big for the target use. THAT is what strict
type checking is about!

-- 
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] new json, push generated file?

[Jakub Zelenka]

On Mon, Feb 9, 2015 at 7:22 PM, Nikita Popov nikita@gmail.com wrote:

 On Mon, Feb 9, 2015 at 3:40 AM, Pierre Joye pierre@gmail.com wrote:

 hi,

 Should we push json_parser.tab.c? Which is generated (re2c), just like
 what is done in date or other?


 We do not include bison generated files in the git repo, because bison is
 already a dependency for building PHP from git. We only include re2c
 generated files. Please keep it that way.

 Nikita


re2c is dependency for building PHP as well so that's really not the
reason, is it? :)

My point here is that I would like to use a new re2c (I'd really love to
use native utf-8 ranges implemented in 0.13.7) and possibly some bison
features (cleaner definitions, nicer %empty rules - that's not of course
necessary but the parser would look nicer :) ). It would be great if I
could have a finer control of the used version for both tools as it's also
critical for perf testing. If you look to my PR, it eliminates user
dependency on the increased re2c version and the same could be used for
bison. There won't be any git conflicts as well... That would be a bit more
complicated in the config.m4 if I had to generate bison files and ignore
re2c. The reason is is a single Makefile.frag that would have to be split
which would mean bigger changes to the build system.

Is there actually any reason why it is better not to have both json
generated files in the repo?

Cheers

Jakub

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Dmitry and Joe,

On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov dmi...@zend.com wrote:

 yes. this may work.
 probably better to put it after extends and implements.


 Dmitry.

 On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins pthre...@pthreads.org wrote:

 Could this be described as a requirement of the class ?

 class Mine
 require(invariant-expr)
 extends Something
 implements Someface {

 public function method($param) : return
 require(input-expr),
 return(output-expr) {

 }
 }

 To avoid invariant keyword maybe.


This would work.
If users have adopted DbC in some way, 'invariant' may be used already.

I see two issues.

Interface works, but most classes are class without interfaces. Then users
have to repeat
require()/return() many times to check class state or have to use interface
for DbC.

Since compiler does not know a method() is for DbC invariant, it will be
compiled and exists
in production execution.

Use of interface:
  - no additional keyword (pros)
  - requires interface for DbC, most classes does not require interface
(cons)
  - if interface is not used, user has to repeat invariant conditions over
and over (cons)
  - requires to define method that should not exist in production (cons)

New keyword:
  - does not require interface for efficient definition (pros).
  - new keyword (cons)

It seems we are better to choose proper keyword for 'invariant'.
'invariant' is not common, so 'invariant'
may be good enough choice. Does anyone use 'invariant' as
function/method/class/constant names?
If there is better name, suggestion is appreciated.

On place closure call like javascript is not supported in PHP, but function
works with assert.

?php
function foo() { return FALSE; }
assert(foo());
?
PHP Warning:  assert(): Assertion failed in - on line 3

This wouldn't be changed for require()/return()/invariant()?

We need a switch to change development/production. I'll use dbc=On/Off
for now.
If you have any better idea, please let me know. (dbc will be INI_SYSTEM)

For CLI, there will be no command line switch for dbc. It executes script
production mode by
default. If user needs development mode

php -d dbc=1 script.php

should be used.


And finally, are we going to allow custom assertion error message? e.g.

require($a  0, 'Parameter $a must be positive number');

Since this contract is definition like implements/extends, we may not
allow
custom error message. I'll write the RFC not to allow custom error messages
unless
you dislike it.

I think we have enough consensus/information to start writing the RFC.
If I have any concern, I'll ask here.

Regards,

P.S. If anyone finds issues with DbC as class definition, please let me
know.

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

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

[Arvids Godjuks]

I actually have a question, that Ferenc touched on, but it never got any
discussion.

How, actually, the declare will work with concatenated PHP files? It's
quite a common practice to put the files into packages, that require
minimal amounts of includes for performance reasons.
Declare is required to be a the top of a file as a first statement. So, if
I have like 10 packages from composer written in different styles, how
should I actually combine them? Stripping the declare from each file and
putting a single declare with the type hint level I want? What will happen
if a library is written for weak type hints ends up in strict type hint
mode? Or the other way around? Isn't it gonna be a mess?

Thanks,
Arvids.

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

[Pierre Joye]

On Mon, Feb 9, 2015 at 3:02 PM, Arvids Godjuks arvids.godj...@gmail.com wrote:
 I actually have a question, that Ferenc touched on, but it never got any
 discussion.

 How, actually, the declare will work with concatenated PHP files? It's
 quite a common practice to put the files into packages, that require
 minimal amounts of includes for performance reasons.
 Declare is required to be a the top of a file as a first statement. So, if
 I have like 10 packages from composer written in different styles, how
 should I actually combine them? Stripping the declare from each file and
 putting a single declare with the type hint level I want? What will happen
 if a library is written for weak type hints ends up in strict type hint
 mode? Or the other way around? Isn't it gonna be a mess?

How do you do it for namespaces? This is the same issue.


Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

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

[Dmitry Stogov]

this is more or less true. :(
The proposal is presented in an unfair way to include strict typing without
the ability to vote for weak types only.

Despite of semantic arguments, the implementation is a bit immature and
introduces slowdown for any code without type hints.

Thanks. Dmitry.



On Mon, Feb 9, 2015 at 7:20 AM, Matthew Leverton lever...@gmail.com wrote:

 On Sun, Feb 8, 2015 at 3:22 PM, Zeev Suraski z...@zend.com wrote:
  I'm well aware of it as I wrote that policy.  The goal of the policy was
 to
  prevent a situation where a temporary majority can introduce features
 into
  the language that would later on be impossible to reverse.  It's not by
 any
  stretch a good mechanism to solve controversial votes, which again,
 should
  ideally be avoided as much as possible.  It's just that there isn't a
 better
  mechanism.
 
 I know I'm unfairly paraphrasing you, but it sounds like you are
 saying that for things that you don't have strong feelings about, then
 you're fine if the others vote amongst themselves. But for things that
 matter to you, you want to reserve the right to prevent change. Is
 there a way to fairly describe what you consider too controversial to
 vote on?

 The problem I see with votes for this type of feature is that you
 probably have a breakdown of something like:

 - 10% of people don't want scalar type hints
 - 20% of people want both, but 50% of them would vote for either weak or
 strong
 - 35% of people want strict, but 80% of them are fine with weak
 - 35% of people want weak, but 80% of them are fine with strong

 So if a strict-only vote happens first, you get 73% to say yes. If
 weak-only vote happens first, you get 73% to say yes.

 (I'm obviously just making up these numbers with no scientific basis,
 but I think the principle is valid.)

 The only way to be fair IMO is to hold a vote where you rank those
 four options (weak, strong, both, neither) and hold an instant run-off
 vote where the first majority wins. And if 'neither' wins, then agree
 that the topic cannot be revisited until next major version, so that
 everybody can rest for 5 years. ;)

 --
 Matthew Leverton

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

Re: [PHP-DEV] Design by Contract

[Pavel Kouřil]

 There are a lot of researches in this field. PHP has a great opportunity to
 not close the doors by forcing a language. I suggest you to offer an API to
 hook on the runtime and “control” it, like AOP does. It will open the doors
 to so many interesting contributions!


Hello,

after reading this discussion, this seems like the best way to handle DbC.


Regards
Pavel Kouril

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

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

[Pierre Joye]

On Mon, Feb 9, 2015 at 3:04 PM, Dmitry Stogov dmi...@zend.com wrote:
 this is more or less true. :(
 The proposal is presented in an unfair way to include strict typing without
 the ability to vote for weak types only.

 Despite of semantic arguments, the implementation is a bit immature and
 introduces slowdown for any code without type hints.

Hm, I have a bad feeling about this argument popping up again now. I
did not see any significant perf degradation using common apps but I
ask Matt to run some tests again using the PR vs master, let discuss
actual subjective numbers instead of raising the performance impact
blocker :)

Cheers,
Pierre

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

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

[Pavel Kouřil]

On Mon, Feb 9, 2015 at 9:04 AM, Dmitry Stogov dmi...@zend.com wrote:
 this is more or less true. :(
 The proposal is presented in an unfair way to include strict typing without
 the ability to vote for weak types only.

 Despite of semantic arguments, the implementation is a bit immature and
 introduces slowdown for any code without type hints.

 Thanks. Dmitry.



This is something I mentioned several times - there should be two
votes. One for weak types and one for adding the strict typing on the
weak typing as a bonus. Not bundling it into one voting, it makes it
feel forced.


Pavel Kouril

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

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

[Pierre Joye]

On Mon, Feb 9, 2015 at 3:19 PM, Pavel Kouřil pajou...@gmail.com wrote:
 On Mon, Feb 9, 2015 at 9:04 AM, Dmitry Stogov dmi...@zend.com wrote:
 this is more or less true. :(
 The proposal is presented in an unfair way to include strict typing without
 the ability to vote for weak types only.

 Despite of semantic arguments, the implementation is a bit immature and
 introduces slowdown for any code without type hints.

 Thanks. Dmitry.



 This is something I mentioned several times - there should be two
 votes. One for weak types and one for adding the strict typing on the
 weak typing as a bonus. Not bundling it into one voting, it makes it
 feel forced.


I am not saying I want one or the other (I have voted and now only
focus on solving possible tech issues we may find) but trying to be
fair with Andrea's RFC and amazing effort:

What you ask is basically part of the RFC already, your code can be
strict free if you wish to, or it will be by default. Only issue is
the massive misunderstanding behind the declare(strict) thing.

Cheers,
Pierre

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

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

[Pavel Kouřil]

On Mon, Feb 9, 2015 at 9:22 AM, Pierre Joye pierre@gmail.com wrote:


 I am not saying I want one or the other (I have voted and now only
 focus on solving possible tech issues we may find) but trying to be
 fair with Andrea's RFC and amazing effort:

 What you ask is basically part of the RFC already, your code can be
 strict free if you wish to, or it will be by default. Only issue is
 the massive misunderstanding behind the declare(strict) thing.

 Cheers,
 Pierre

I'm not saying one or the other - I mean two votes, one for the
basic weak typing and if it passes, then vote for adding the
declareable optional strict typing. Now it is unfortunately both or
neither.

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

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

[Pierre Joye]

On Mon, Feb 9, 2015 at 3:30 PM, Pavel Kouřil pajou...@gmail.com wrote:
 On Mon, Feb 9, 2015 at 9:22 AM, Pierre Joye pierre@gmail.com wrote:


 I am not saying I want one or the other (I have voted and now only
 focus on solving possible tech issues we may find) but trying to be
 fair with Andrea's RFC and amazing effort:

 What you ask is basically part of the RFC already, your code can be
 strict free if you wish to, or it will be by default. Only issue is
 the massive misunderstanding behind the declare(strict) thing.

 Cheers,
 Pierre

 I'm not saying one or the other - I mean two votes, one for the
 basic weak typing and if it passes, then vote for adding the
 declareable optional strict typing. Now it is unfortunately both or
 neither.

because you have both already. Your code is not affected unless you
use strict=1, even if the libs your code relies on actually use
strict=1. In other words, this RFC proposes both worlds in one shot. I
see the votes for two as redundant or killing the root idea behind
this RFC.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

Hi,

I'll try to answer to all the emails at once.

Personally, I like the D approach more, but doc-comment proposal has its
advantages as well.
The problem that doc-comment solution is external to PHP core.
In my opinion, it should be implemented as a separate preprocessor that
reads doc-comments and generates PHP code with asserts().
I don't see how this may be implemented in PHP core itself, and I most
probably won't be evolved in development of other project.
Something similar was already implemented...
Alexander, could you please send link to implentation/dicumentation and
explain how it works (in few words).

Yasuo, I think you should describe the D proposal as well. I'm not sure if
it should be done in the same RFC (it's already big) or a new one.

Any solution would require zero-cost assert (or similar concept)
implemented in php core.

Thanks. Dmitry.



On Mon, Feb 9, 2015 at 8:52 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Guilherme,

 On Mon, Feb 9, 2015 at 1:44 PM, guilhermebla...@gmail.com 
 guilhermebla...@gmail.com wrote:

 Class invariants could be done as this example:

 class Foo {
 private function isValidState() {
 // Checks class's state and returns boolean
 }

 public function doSomething($args) {
 // Some complex operation over Foo instance using $args
 // then...

 assert $this-isValidState(): $this; // it would call
 Foo::__toString() for AssertionError message
 }
 }

 Another example of pre and post conditions:

 function foo($number) {
 // pre-condition
 assert is_numeric($number): '...';

 // Some expensive operation creating $value as response

 // post-condition
 assert someCheckWith($value): '...';
 return $value;
 }

 A good explanation about use-cases can be found here
 http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#class-invariants


 Thank you for the info.

 I had this syntax in mind.

 class Foo {
__invariant() {
   // Ignored for production.
   // Check class state, every method calls invoke this method
 before/after except
   //  __construct()/__wakeup()/__set_state() - after only
   //  __destruct() - before only
}
 }

 // Framework developer shouldn't use this. Leave this function for app
 developers.
 function __invariant() {
   // Ignored for production.
   // Invariant conditions of functions invoked for every function calls
   // to check app state. e.g. global vars,etc
 }

 __invariant() has similar issue as __autoload(), we may be better to
 provide generic registration
 method.

 Just my initial thought for discussion.

 Regards,

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

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

It's nothing wrong here. It's just a concept that cares about constraints
definition more.

So, DbC with asserts spread among the code is like OOP without classes.

Thanks. Dmitry.


On Mon, Feb 9, 2015 at 2:11 AM, Stanislav Malyshev smalys...@gmail.com
wrote:

 Hi!

  Following our conversation, I tried to imagine how DbC should look like
 in
  PHP from user perspective. Finally, I was influenced by the semantic
  proposed in D, and syntax proposed for Java. So, these are my initial
  thoughts:
 
  For php it may look like the following:
 
  function foo()
  requre(input-assert-expression)
  ensure(output-assert-expression)
  {
...
  }

 Why not do it simpler?

 function foo() {
 // require
 assert(input-assert-expression);
 ...
 // ensure
 assert(output-assert-expression);
 }

 I'm oversimplifying a bit, but in general, why we need more places to
 have code in the function than the actual code of the function? It would
 be harder to parse, to read, to maintain, to debug, to profile, etc. and
 I'm not sure what exactly it provides that can't be done by plain
 regular code inside the function.

 If we're concerned about the costs of assert, we could make special
 provision in the compiler for zero-cost asserts. It doesn't require
 moving code out of the function.
 --
 Stas Malyshev
 smalys...@gmail.com

Re: [PHP-DEV] Design by Contract

[Patrick Schaaf]

Am 10.02.2015 08:08 schrieb Yasuo Ohgaki yohg...@ohgaki.net:

 One reason I would like to use __invariant() is to allow overriding
parents.
 I think we should have way for it, but I don't have good idea now.
 I'm still thinking.

Hmm, Idea... Imagine the require keyword, in the context of classes, as an
alternative to the function keyword. One could write any of these:

class foo {
   require (expr); // like anonymous function. nonoverridable
   static require (expr); // same for nonmethod calls
   // _named_ form
   require something (expr);  // overrides
   static require otherthing (expr); // overrides
}

This way selective overriding would be possible for individual conditions.

The namespace for these invariant expression names could / should be wholly
separate from the method namespace itself.

best regards
  Patrick

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Patrick,

On Tue, Feb 10, 2015 at 4:06 PM, Patrick Schaaf p...@bof.de wrote:

 Am 10.02.2015 07:25 schrieb Yasuo Ohgaki yohg...@ohgaki.net:
 
  https://wiki.php.net/rfc/dbc2

 First of all, thanks for your effort so far.

 Some questions, after reading the RFC, with no particular order:

 1) Regarding invariants: those will be called for method calls on objects.
 What about static class methods? Could we have static class invariants
 (static require(.))? Would these be called for both static and
 nonstatic method calls (nonstatic method calls can change static class
 state, too)

Static calls should not use $this-var, so invariant condition is ignored.
It should be in the RFC.

 2) the pre- and postconditions could be useful for ordinary, non-OO
 functions, too, to check parameters, return, and global state invariants

I proposed __invariant() function, but some would not like to have it.
Since you've requested, we may consider again.

Rre/postconditions (require/return) can be used for non-OO functions.
It should be in the RFC. I'll add it in the RFC later.

 3) I think that method preconditions are not sufficient. Pretty often,
 public methods first sanitize and validate their input parameters, and
 rightly so. In these cases, it would be useful to have the checking, in the
 same general framework, at an arbitrary point in the function body. In
 other words, assert (with an expression as the first argument, instead of a
 string).

I might misunderstand you. Anyway,

assert( $var  0 )

is allowed. So you can write usual PHP code. Even we can

assert( foo() ) // The same applies to require()/return()

is allowed. However, PHP does not allow in place closure call currently. We
cannot do

assert(function() { return $a  0;} )

It's just ignored. This is the same as current assert().

 4) regarding the error message second argument to the condition
 definitions, it would be useful to have these not only as plain
 (extrapolated) strings, but as full expressions-that-evaluate-to-string.
 That would permit hooking to arbitrary private logging and log formatting
 methods.

assert( $var  0, '$var must be positive')

is allowed.
This should be in the RFC. require()/return() works just like assert().


 5) and a bit off-topic, it would be useful to be able to declare (sic)
 whole methods to be nonproduction only: Methods that will only be used in
 pre/post/invariant condition expresions (or error formatters a la my point
 4)


Do you mean enable DbC partially? Like

declare(dbc=1);

At the top of script?
I think it would not happen, but others may think it should.
Anyone?

Regards,

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

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

 One reason I would like to use __invariant() is to allow overriding
parents.

Well, another approach would be optionally named contracts:

class Some {
require contractName (invariant-expr);
/* ... */
}

This would also improve default error messages as a by-product.

Cheers
Joe

On Tue, Feb 10, 2015 at 7:06 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Joe,

 On Tue, Feb 10, 2015 at 3:59 PM, Joe Watkins pthre...@pthreads.org
 wrote:

 I'm not sure we can always enforce invariant contracts ...

 Evaluating invariant expressions on entry and exit is not enough, since a
 property can be changed without the use of a method.

 Can or should, we do anything about that ?

 This should also be covered in the RFC, I think.


 One reason I would like to use __invariant() is to allow overriding
 parents.
 I think we should have way for it, but I don't have good idea now.
 I'm still thinking.

 Regards,

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

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

Example code never works, I can just say that's a bad abstraction,
vertebrate and invertebrate are distinct and abstraction should reflect
that.

Why should we provide a way to change contracts is the question ?

It doesn't seem to make sense to do that, a derived class should be able to
define additional contracts, but not change the contracts of it's parent.

Cheers
Joe

On Tue, Feb 10, 2015 at 7:36 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Joe,

 On Tue, Feb 10, 2015 at 4:31 PM, Joe Watkins pthre...@pthreads.org
 wrote:

 Actually I'm not sure it's at all sane to try to override contracts, I'd
 actually avoid that completely, so no need to name contracts and no need
 for magic __invariant.


 For example,

 class Animal {
protected $legs;
require($legs = 0);
 }

 class Snake extends Animal {
   // Snake is fine, no leg
 }

 class Human extends Animal {
   // 2 legs. $this-leg === 2
 }

 Overriding makes sense for many cases.

 Regards,

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

Re: [PHP-DEV] Design by Contract

[Patrick Schaaf]

Am 10.02.2015 08:25 schrieb Yasuo Ohgaki yohg...@ohgaki.net:

 5) and a bit off-topic, it would be useful to be able to declare (sic)
whole methods to be nonproduction only: Methods that will only be used in
pre/post/invariant condition expresions (or error formatters a la my point
4)

 Do you mean enable DbC partially? Like
 declare(dbc=1);
 At the top of script?

Nono. i shouldn't have said declare, sorry.

What I meant is this (using a made-up keyword dbconly just for
exposition):

class foo {
   function normalmethod($arg)
   require($this-just_for_dbc_check($arg))
   {  }
   dbconly function just_for_dbc_check($arg) {
   ... whatever validation code ...
   return false;
   }
}

And then when DbC is inactive (production) metho just_for_dbc_check would
not be compiled at all / invisible.

I now realize that I'm asking for a way to have arbitrary PHP code for
checking, through a backdoor :)

But this _would_ permit some nice consolidation of more complex checks,
ones that maybe would be shared by several methods with repetition of the
expressions in the case we cannot do this.

Just thinking out loud, I fully agree with Dmitry's comment of keeping it
simple and manageable at the moment, and this is something that could be
added later at any time.

best regards
  Patrick

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Dmitry,

On Tue, Feb 10, 2015 at 4:21 PM, Dmitry Stogov dmi...@zend.com wrote:

 4) regarding the error message second argument to the condition
 definitions, it would be useful to have these not only as plain
 (extrapolated) strings, but as full expressions-that-evaluate-to-string.
 That would permit hooking to arbitrary private logging and log formatting
 methods.

 I don't think we will implement this. It may be proposed later as a DbC
 extension.


I thought it works just like assert(), but no problem for me.


 5) and a bit off-topic, it would be useful to be able to declare (sic)
 whole methods to be nonproduction only: Methods that will only be used in
 pre/post/invariant condition expresions (or error formatters a la my point
 4)

 this is also not directly related as well.
 Sorry, but we should define realistic target to be able to provide a
 working solution.
 We can't think about all possible and indirectly related features at once.


I agree.

Regards,

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

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Joe,

On Tue, Feb 10, 2015 at 4:31 PM, Joe Watkins pthre...@pthreads.org wrote:

 Actually I'm not sure it's at all sane to try to override contracts, I'd
 actually avoid that completely, so no need to name contracts and no need
 for magic __invariant.


For example,

class Animal {
   protected $legs;
   require($legs = 0);
}

class Snake extends Animal {
  // Snake is fine, no leg
}

class Human extends Animal {
  // 2 legs. $this-leg === 2
}

Overriding makes sense for many cases.

Regards,

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

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

On Tue, Feb 10, 2015 at 10:06 AM, Patrick Schaaf p...@bof.de wrote:

 Am 10.02.2015 07:25 schrieb Yasuo Ohgaki yohg...@ohgaki.net:
 
  https://wiki.php.net/rfc/dbc2

 First of all, thanks for your effort so far.

 Some questions, after reading the RFC, with no particular order:

 1) Regarding invariants: those will be called for method calls on objects.
 What about static class methods? Could we have static class invariants
 (static require(.))? Would these be called for both static and
 nonstatic method calls (nonstatic method calls can change static class
 state, too)

yeah, static require() may be a good addition. However, I don't like to
invite a bicycle, we are going to borrow most related semantic from D.

 2) the pre- and postconditions could be useful for ordinary, non-OO
 functions, too, to check parameters, return, and global state invariants

any function will able to use contracts.

3) I think that method preconditions are not sufficient. Pretty often,
 public methods first sanitize and validate their input parameters, and
 rightly so. In these cases, it would be useful to have the checking, in the
 same general framework, at an arbitrary point in the function body. In
 other words, assert (with an expression as the first argument, instead of a
 string).

assert() will work as well. Actually, all these addition require/return
syntax is going to be just a syntax sugar that will finally call assert()s
in proper order.

 4) regarding the error message second argument to the condition
 definitions, it would be useful to have these not only as plain
 (extrapolated) strings, but as full expressions-that-evaluate-to-string.
 That would permit hooking to arbitrary private logging and log formatting
 methods.

I don't think we will implement this. It may be proposed later as a DbC
extension.

 5) and a bit off-topic, it would be useful to be able to declare (sic)
 whole methods to be nonproduction only: Methods that will only be used in
 pre/post/invariant condition expresions (or error formatters a la my point
 4)

this is also not directly related as well.
Sorry, but we should define realistic target to be able to provide a
working solution.
We can't think about all possible and indirectly related features at once.

Thanks. Dmitry.



 best regards
   Patrick

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

Actually I'm not sure it's at all sane to try to override contracts, I'd
actually avoid that completely, so no need to name contracts and no need
for magic __invariant.

Cheers
Joe

On Tue, Feb 10, 2015 at 7:26 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Dmitry,

 On Tue, Feb 10, 2015 at 4:21 PM, Dmitry Stogov dmi...@zend.com wrote:

  4) regarding the error message second argument to the condition
  definitions, it would be useful to have these not only as plain
  (extrapolated) strings, but as full expressions-that-evaluate-to-string.
  That would permit hooking to arbitrary private logging and log
 formatting
  methods.
 
  I don't think we will implement this. It may be proposed later as a DbC
  extension.
 

 I thought it works just like assert(), but no problem for me.


  5) and a bit off-topic, it would be useful to be able to declare (sic)
  whole methods to be nonproduction only: Methods that will only be used
 in
  pre/post/invariant condition expresions (or error formatters a la my
 point
  4)
 
  this is also not directly related as well.
  Sorry, but we should define realistic target to be able to provide a
  working solution.
  We can't think about all possible and indirectly related features at
 once.
 

 I agree.

 Regards,

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

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

[Andrey Andreev]

Hi,

On Mon, Feb 9, 2015 at 7:22 PM, Jordi Boggiano j.boggi...@seld.be wrote:

 And that is exactly why this RFC is great, since it lets the
 strict-proponents have their strict types in their files, but those
 preferring weak ones can remain in the default weak mode, never see an ugly
 declare(), and still call strict code in weak mode.

 That is why I don't quite understand the no votes coming from weak-hints
 proponents. Unless of course you would prefer to pass weak-only v0.1 and
 then shoot down any attempt at strict hints. That strikes me as quite
 selfish though, given the strict-proponents isn't such a tiny group of
 people.

 And then there are the people sitting somewhere in between the black and
 white camps. Those that would like to use strict sometimes for some critical
 code paths, and for them the proposed solution is quite good as well.


I am in the between black and white camp and this RFC doesn't give
me what I want, nor did the 0.1 version of it.
I would vote 'no' on both if I had voting privileges.

Please, all, stop speculating and just let the votes count.

Cheers,
Andrey.

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

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

[guilhermebla...@gmail.com]

Hi,

I read again and again the RFC and I just decided to switch my vote.
Originally a YES voter, I'm now a NO voter. I still want strict types
to exist in PHP, and not only at the end-user level, but also at the
internals level (I can see so many optimizations around...).
However, I think it's not an INI setting or a per file operation. I
consider it should be (at the current PHP's pace) a heavily flexible
support. I tend to agree that if you put string in its definition, you
don't want a weak type, but strict type, the same way when you put MyClass
instead of nothing.

That's why I don't agree with the declare or use strict or ?php strict.
If I say string $foo, I want a string, not a converted value. By
accepting this fact, makes easier in the future to make OO primitive types
if we wish, and also makes everything easier for everyone... if you have
foo(string $name), you expect strict type... if you want weak type,
foo($name). All code will work as is today, no BC breaks.

That's my 2 cents... now time to update my vote in RFC.

[]s,


On Mon, Feb 9, 2015 at 1:02 PM, Andrey Andreev n...@devilix.net wrote:

 Hi,

 On Mon, Feb 9, 2015 at 7:22 PM, Jordi Boggiano j.boggi...@seld.be wrote:
 
  And that is exactly why this RFC is great, since it lets the
  strict-proponents have their strict types in their files, but those
  preferring weak ones can remain in the default weak mode, never see an
 ugly
  declare(), and still call strict code in weak mode.
 
  That is why I don't quite understand the no votes coming from
 weak-hints
  proponents. Unless of course you would prefer to pass weak-only v0.1 and
  then shoot down any attempt at strict hints. That strikes me as quite
  selfish though, given the strict-proponents isn't such a tiny group of
  people.
 
  And then there are the people sitting somewhere in between the black and
  white camps. Those that would like to use strict sometimes for some
 critical
  code paths, and for them the proposed solution is quite good as well.
 

 I am in the between black and white camp and this RFC doesn't give
 me what I want, nor did the 0.1 version of it.
 I would vote 'no' on both if I had voting privileges.

 Please, all, stop speculating and just let the votes count.

 Cheers,
 Andrey.

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




-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP

[Rowan Collins]

S.A.N wrote on 09/02/2015 17:40:

2015-02-09 12:41 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:

Yes, I can see it working well for specialised uses - you can simply not use 
those aspects of the language that don't make sense. But for it to be a 
mainstream part of the language, it needs to play nicely with other parts of 
the language, and that's where I see it being a complex and painful change.


The fact that the lack of native application server for PHP is often
the reason for leaving the PHP developers to other languages and
technologies.

Let's see what others have in 2015:

Python - WSGI
Ruby - Rack
Perl - PSGI
JavaScript - JSGI
Hack - HHVM

PHP - No native application server in core.

What discusses the PHP community?
Remove or not to remove the PHP4 constructors and many other issues
that do not add competitive ability PHP...

I personally do not blame you :), just expressing his opinion
developer who wants to use PHP and can use modern app server in core
PHP.



The sentence you're replying to there is talking about existing 
implementations, on top of current PHP, with all the limitations that 
implies.


My view on the general idea of changing the language so that eventually 
an event-based model could be the norm, is in an earlier reply:


 Not that I don't like the idea, but it's a huge project, with 
potential for profoundly affecting the language.



Regards,
--
Rowan Collins
[IMSoP]

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

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

[Andrea Faulds]

Hi Zeev,

 On 9 Feb 2015, at 17:03, Zeev Suraski z...@zend.com wrote:
 
 I'll make an absolute last attempt to explain what I'm saying, after that
 we can agree to disagree.  We probably interpret the same facts
 differently.
 
 Fact is, there were very few people who said that weak types are *bad*
 (although Sebastian seems to fall in that category).  The vast majority of
 feedback that 'opposed' weak typing, didn't really oppose weak typing at
 all.  What it opposed was, rather, the lack of introducing strict typing.
 That is clearly not the same thing, which is why the fact there were
 people who opposed v0.1 of the RFC does not equate with people opposing
 weak typing, not at all.
 
 Each and every person that voted in favor of the v0.3 RFC, voted in favor
 of weak typing.  Weak typing is not only a key element of that RFC - it's
 even the default behavior.  In addition to everyone who voted in favor of
 the v0.3 RFC, many - most probably most of the people who voted against
 it- are in favor of the weak typing API.  If you combine the two groups,
 you're going to get to nearly 100% support, or arguably, 'lack of
 opposition', to the weak typing proposal.

First off, it’s really unfair to claim that merely because someone votes for 
this RFC, that they are okay with weak typing. It’s a compromise proposal: I’m 
not a big fan of weak typing, not by any means, and plenty of other people 
aren’t either, but this RFC allows me to use strict typing and others to use 
weak typing, without us getting in each other’s way. So, I am in favour of this 
RFC. I *do not like* weak typing. But I am willing to vote for and push for 
this RFC, if it means we’ll get scalar types somehow (and, crucially, it allows 
*strict* scalar types). People who are in favour of this RFC are *not* 
necessarily in favour of weak types, or adding weak types on their own.

Anyway, to the main point. I’m pretty sure that you’re wrong in saying that the 
vast majority of the people who opposed the introduction of weak scalar types, 
and *only* weak scalar types in the v0.1 RFC, were actually okay with weak 
typing. That does not go with my experiences at all. From what I have seen, a 
large number of people are opposed to weakly-typed parameters, period.

But let’s assume that you’re correct for a moment. Let’s say that, 
hypothetically, 100% of the people in the v0.1 thread (absolute consensus, 
then) had no opposition to the idea of weak typing, and the only complaint 
anyone had was that strict typing wasn’t also being added.

This doesn’t help your case. In fact, it hurts it.

Firstly, while there may be this hypothetical consensus around weak types, the 
v0.1 RFC showed there was definitely NOT consensus around adding weak types *on 
their own*. Yet that was what you are arguing: that their would be consensus, 
or is consensus, around just adding weak types. So, merely adding weak types, 
and not strict types, is not something there’s a consensus on, and is not 
something everyone can agree on, despite what you have been arguing.

Secondly, you are saying that the only opposition to v0.1 was that it did not 
also introduce strict types. So, therefore, this new version of the RFC which 
introduces strict typing alongside weak typing, should surely be more popular, 
no?

I do not understand your logic.

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





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

Re: [PHP-DEV] Annotated PHP 5-7 extension diff

[Lester Caine]

On 09/02/15 15:03, Jan Ehrhardt wrote:
 Despite the extensive list of changes, imagick does not compile anymore
 with the current PHP7 git head (Win32 VC11).

OK another day wasted but I am getting the development platform stable.

http://lsces.org.uk/phpinfo.php is my production copy, but has a broken
imagick and an out of date smarty library.

http://php7.lsces.org.uk/phpinfo.php has everything it needs and is
currently only giving nginx errors in the log

http://php56.lsces.org.uk/phpinfo.php has the latest 5.6 from git but
mbstring will not compile

http://php6.lsces.org.uk/phpinfo.php is the distributed PHP5.6.5 dump
and everything seems to be working same as php7 build, except imagick
crashes phpinfo() as does the php56 build.

Just need to restore the production copy to fully functional before I
get back to debugging the new stuff.

( Have some facilities set up in Eclipse but would still appreciate some
input on that for compiling source rather than managing php projects )

-- 
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] [VOTE] Scalar Type Hints

[guilhermebla...@gmail.com]

Hi Andrea,

I totally see your viewpoint. That's why initially I voted YES, because
your proposal somehow makes sense.
My when I thought over and use a weak/strict boolean type conversion on my
own brain, I came to the conclusion my real wish does not get fully
addressed with a YES, leading me to switch my vote.
I really wanted to expose the motivation of my change here, so everyone is
aware that I do love strict typing, and I really want this in for PHP, but
not in this RFC way.

[]s,

On Mon, Feb 9, 2015 at 1:19 PM, Andrea Faulds a...@ajf.me wrote:

 Hi Guilherme,

  On 9 Feb 2015, at 18:12, guilhermebla...@gmail.com wrote:
 
  I read again and again the RFC and I just decided to switch my vote.
  Originally a YES voter, I'm now a NO voter. I still want strict types
  to exist in PHP, and not only at the end-user level, but also at the
  internals level (I can see so many optimizations around...).
  However, I think it's not an INI setting or a per file operation. I
  consider it should be (at the current PHP's pace) a heavily flexible
  support. I tend to agree that if you put string in its definition, you
  don't want a weak type, but strict type, the same way when you put
 MyClass
  instead of nothing.
 
  That's why I don't agree with the declare or use strict or ?php
 strict.
  If I say string $foo, I want a string, not a converted value. By
  accepting this fact, makes easier in the future to make OO primitive
 types
  if we wish, and also makes everything easier for everyone... if you have
  foo(string $name), you expect strict type... if you want weak type,
  foo($name). All code will work as is today, no BC breaks.
 
  That's my 2 cents... now time to update my vote in RFC.

 I can understand that viewpoint, but it’s not terribly kind on your users.
 You’re basically saying that you want to force people who’d prefer weak
 typing to use strict typing if they use your API. It’s doing this which
 this RFC is designed to prevent. I don’t think allowing people to force
 their way on their users is a good way to deal with the lack of weak or
 strict consensus in the community, no matter whether it’s nice for API
 design or not.

 Thanks.

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







-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

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

[Philip Sturgeon]

On Mon, Feb 9, 2015 at 1:22 PM, Lars Strojny l...@strojny.net wrote:
 Hi Matteo,

 sorry for the late response.

 On 07 Feb 2015, at 12:46, Matteo Beccati p...@beccati.com wrote:

 Maybe it's just me, but I didn't quite understand the point you are making 
 here. Are you saying that declares are more or less like ini settings?

 Yes, exactly that. The new declare()-statement will fundamentally change how 
 the engine behaves and one will have two learn more or less two flavors of 
 PHP. Even worse I am forced to use the PHP flavor the person picked who 
 changed the declare() statement last.

 cu,
 Lars

This is strange for me to understand but I do see it come up a lot.

if you have foo(string $name), you expect strict type... if you want
weak type, foo($name). All code will work as is today, no BC breaks.

No. If I have foo(string $name), I expect a string. I don't care if
its strong or weak, I just want a string. The weak or strong bit is up
to the user, which is why they're the ones holding the switch.

While I understand the wish to preach best practices to the PHP
community in general - because heck knows some people need it - this
is more of an entry for phptherightway.com than the job of every
single library author to try and force the community ot use strict
typing one library at a time.

The function author doesn't need to care if its strong or weak. They
just need to care that they have the right type. And they will, every
time.

Using foo($name) will give me the wrong types, so no thanks on that :)

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

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

[Andrea Faulds]

Hi,

 On 9 Feb 2015, at 18:22, Lars Strojny l...@strojny.net wrote:
 
 On 07 Feb 2015, at 12:46, Matteo Beccati p...@beccati.com wrote:
 
 Maybe it's just me, but I didn't quite understand the point you are making 
 here. Are you saying that declares are more or less like ini settings?
 
 Yes, exactly that. The new declare()-statement will fundamentally change how 
 the engine behaves

It’s a relatively minor change. It changes how arguments and return values are 
type-checked, that’s all. The patch isn’t that complex.

 and one will have two learn more or less two flavors of PHP.

Hardly, the differences are not that big. One’s slightly stricter when checking 
arguments and return values, but that’s it. It’s not two completely different 
worlds, it’s a minor detail of personal preference.

 Even worse I am forced to use the PHP flavor the person picked who changed 
 the declare() statement last.

Well, yes, in a project with multiple people, you must conform to the project 
style guide and such, that’s hardly unusual.

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





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

Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP

[Albert Casademont Filella]

HHVM is a FastCGI interface, just like PHP-FPM is, I don't see your point
here!

On Mon, Feb 9, 2015 at 6:40 PM, S.A.N ua.san.a...@gmail.com wrote:

 2015-02-09 12:41 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
  Yes, I can see it working well for specialised uses - you can simply not
 use those aspects of the language that don't make sense. But for it to be a
 mainstream part of the language, it needs to play nicely with other parts
 of the language, and that's where I see it being a complex and painful
 change.
 

 The fact that the lack of native application server for PHP is often
 the reason for leaving the PHP developers to other languages and
 technologies.

 Let's see what others have in 2015:

 Python - WSGI
 Ruby - Rack
 Perl - PSGI
 JavaScript - JSGI
 Hack - HHVM

 PHP - No native application server in core.

 What discusses the PHP community?
 Remove or not to remove the PHP4 constructors and many other issues
 that do not add competitive ability PHP...

 I personally do not blame you :), just expressing his opinion
 developer who wants to use PHP and can use modern app server in core
 PHP.

 Thank.

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

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

[Philip Sturgeon]

On Mon, Feb 9, 2015 at 12:03 PM, Zeev Suraski z...@zend.com wrote:
 -Original Message-
 From: Andrea Faulds [mailto:a...@ajf.me]
 Sent: Monday, February 09, 2015 12:44 PM
 To: Zeev Suraski
 Cc: Jordi Boggiano; internals@lists.php.net
 Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints

 Hi,

  On 9 Feb 2015, at 03:48, Zeev Suraski z...@zend.com wrote:
 
  A - has pretty much everybody agreeing with is a good idea.  Nobody
 objects to it.  It's under consensus.

 This isn't true. I've explained why it isn't true several times. Maybe
 you are
 suffering from confirmation bias or something, but there is no such
 consensus. Quite a few internals contributors liked v0.1. Quite a few
 didn't.
 I've gone and evidenced this before in replies sent directly to you.

 Andrea,

 I'll make an absolute last attempt to explain what I'm saying, after that
 we can agree to disagree.  We probably interpret the same facts
 differently.

 Fact is, there were very few people who said that weak types are *bad*
 (although Sebastian seems to fall in that category).  The vast majority of
 feedback that 'opposed' weak typing, didn't really oppose weak typing at
 all.  What it opposed was, rather, the lack of introducing strict typing.
 That is clearly not the same thing, which is why the fact there were
 people who opposed v0.1 of the RFC does not equate with people opposing
 weak typing, not at all.

 Each and every person that voted in favor of the v0.3 RFC, voted in favor
 of weak typing.  Weak typing is not only a key element of that RFC - it's
 even the default behavior.  In addition to everyone who voted in favor of
 the v0.3 RFC, many - most probably most of the people who voted against
 it- are in favor of the weak typing API.  If you combine the two groups,
 you're going to get to nearly 100% support, or arguably, 'lack of
 opposition', to the weak typing proposal.

Woah there Zeev, please take your words out of my mouth, and out of
the mouths of 48 other people.

I voted Yes for this RFC because default weak and optional strict is a
perfectly PHP-way™ to get this job done.

You really have to stop speaking for other people, or this
conversation is going to go off the rails for eternity. We can speak
for ourselves.

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

Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions

[Albert Casademont Filella]

Just a quick side one, there's no way to make compatible calls from mcrypt
to openssl using rijndael-192 and rijndael-256 ciphers, a compatibility
layer is almost impossible. Only AES-128/192/256 (which variants of
rijndael-128) are possible on both extensions.

On Mon, Feb 9, 2015 at 6:47 PM, Pascal MARTIN, AFUP 
mail...@pascal-martin.fr wrote:


 Le 02/02/2015 20:11, Anatol Belski a écrit :

 https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
 voting. Each item is voted separately. The voting ends on 2015-02-09 at
 21:00 CET.


 Hi,

 After discussing this RFC with other people at AFUP (we weren't that many
 to participate in this discussion -- which probably indicates not many of
 us care about keeping those), it seems we would be:

  * +1 to remove all SAPIs listed in this RFC
  * +1 to remove ext/imap and ext/mcrypt -- some of us would have preferred
 keeping those, but a new major version feels like the right time to drop
 them, if the underlying libraries aren't maintained anymore.
  * +1 to remove ext/mssql and ext/sybase_ct
  * and +0 for ext/pdo_dblib -- we didn't reach a consensus on that one.

 Thanks

 --
 Pascal MARTIN, AFUP - French UG
 http://php-internals.afup.org/

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

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

[Andrea Faulds]

Hi Guilherme,

 On 9 Feb 2015, at 18:12, guilhermebla...@gmail.com wrote:
 
 I read again and again the RFC and I just decided to switch my vote.
 Originally a YES voter, I'm now a NO voter. I still want strict types
 to exist in PHP, and not only at the end-user level, but also at the
 internals level (I can see so many optimizations around...).
 However, I think it's not an INI setting or a per file operation. I
 consider it should be (at the current PHP's pace) a heavily flexible
 support. I tend to agree that if you put string in its definition, you
 don't want a weak type, but strict type, the same way when you put MyClass
 instead of nothing.
 
 That's why I don't agree with the declare or use strict or ?php strict.
 If I say string $foo, I want a string, not a converted value. By
 accepting this fact, makes easier in the future to make OO primitive types
 if we wish, and also makes everything easier for everyone... if you have
 foo(string $name), you expect strict type... if you want weak type,
 foo($name). All code will work as is today, no BC breaks.
 
 That's my 2 cents... now time to update my vote in RFC.

I can understand that viewpoint, but it’s not terribly kind on your users. 
You’re basically saying that you want to force people who’d prefer weak typing 
to use strict typing if they use your API. It’s doing this which this RFC is 
designed to prevent. I don’t think allowing people to force their way on their 
users is a good way to deal with the lack of weak or strict consensus in the 
community, no matter whether it’s nice for API design or not.

Thanks.

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





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

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

[Jordi Boggiano]

On 09/02/2015 17:03, Zeev Suraski wrote:

Fact is, there were very few people who said that weak types are *bad*
(although Sebastian seems to fall in that category).  The vast majority of
feedback that 'opposed' weak typing, didn't really oppose weak typing at
all.  What it opposed was, rather, the lack of introducing strict typing.
That is clearly not the same thing, which is why the fact there were
people who opposed v0.1 of the RFC does not equate with people opposing
weak typing, not at all.


The problem is: what's in it for the strict camp to vote yes for a v0.1 
that offers no guarantee that strict hints will be added later nor in 
which form that would happen?


If there is no guarantee, having weak hints in the language is actually 
a bad thing for them since it might mean strict ones never materialize.



Each and every person that voted in favor of the v0.3 RFC, voted in favor
of weak typing.  Weak typing is not only a key element of that RFC - it's
even the default behavior.  In addition to everyone who voted in favor of
the v0.3 RFC, many - most probably most of the people who voted against
it- are in favor of the weak typing API.  If you combine the two groups,
you're going to get to nearly 100% support, or arguably, 'lack of
opposition', to the weak typing proposal.


As per my answers above, I don't think this is true, unless they have no 
clue how politics work.



The controversy is exclusively around strict typing.  It goes both ways -
proponents of strict typing feel very passionate about having to introduce
it into the language;  Opponents seem to feel equally passionate about not
adding them.


And that is exactly why this RFC is great, since it lets the 
strict-proponents have their strict types in their files, but those 
preferring weak ones can remain in the default weak mode, never see an 
ugly declare(), and still call strict code in weak mode.


That is why I don't quite understand the no votes coming from 
weak-hints proponents. Unless of course you would prefer to pass 
weak-only v0.1 and then shoot down any attempt at strict hints. That 
strikes me as quite selfish though, given the strict-proponents isn't 
such a tiny group of people.


And then there are the people sitting somewhere in between the black and 
white camps. Those that would like to use strict sometimes for some 
critical code paths, and for them the proposed solution is quite good as 
well.


Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

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

Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP

[S.A.N]

2015-02-09 12:41 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
 Yes, I can see it working well for specialised uses - you can simply not use 
 those aspects of the language that don't make sense. But for it to be a 
 mainstream part of the language, it needs to play nicely with other parts of 
 the language, and that's where I see it being a complex and painful change.


The fact that the lack of native application server for PHP is often
the reason for leaving the PHP developers to other languages and
technologies.

Let's see what others have in 2015:

Python - WSGI
Ruby - Rack
Perl - PSGI
JavaScript - JSGI
Hack - HHVM

PHP - No native application server in core.

What discusses the PHP community?
Remove or not to remove the PHP4 constructors and many other issues
that do not add competitive ability PHP...

I personally do not blame you :), just expressing his opinion
developer who wants to use PHP and can use modern app server in core
PHP.

Thank.

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

Re: [PHP-DEV] Re: Design by Contract

[Yasuo Ohgaki]

Hi Stas,

On Tue, Feb 10, 2015 at 9:24 AM, Stanislav Malyshev smalys...@gmail.com
wrote:

  constraints. Type check is one of them. There are many people argue This
  language is secure and robust because it has _static_ types.

 These people are wrong. Languages can't really be secure or robust, only
 code implemented in these languages can, and we have witnessed many
 examples of vulnerable code written in pretty much any widely used
 language. Having strict typing may protect against some very basic
 errors, but in well-designed and well-tested software such errors would
 be rare, and in badly designed software type strictness would not save you.


I agree partially. DbC encourages users to adopt secure coding best
practices.
Over all input/output must be controlled by programmers. This is secure
programming
best practice described in many security standards/guidelines. DbC
encourages it.
As you mentioned, well designed softwares do not have issues. DbC does not
solve issues directly, but encourage good design. As a result, program
becomes
more secure/robust.

If one have good design already, they don't have to adopt DbC for better
design.



  Here comes DbC, once we have contracts for pre/post conditions. We are
  safe from calling functions with invalid parameters during development,
 yet
  we have optimum performance for production since there is zero contract
  checks
  with production mode including opcode.

 That assumes perfect test coverage in development, both code-wise and,
 more importantly, data-wise. Which is impossible. While having assert
 primitives that can be turned on and off looks like a useful concept to
 me, I don't think it is some kind of magic solution that will change
 everything.


Over all input/output controls are important for all application. This is
 MUST
requirement for DbC design to be successful.

With DbC, functions called in deep call chains will not check input
validity in
production mode. Therefore, DbC adopters must control over all inputs
at appropriate place (right after input was available to programmers) which
is security best practice.

Misuse of DbC increase risks in fact. DbC requires good design, too.
It's not an automatic solution as you describe.

Thank you for bring this topic.

Regards,

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

[PHP-DEV] [RFC][DISCUSSION] Script only includes

[Yasuo Ohgaki]

Hi all,

Some of you are tired with this topic, but please take a look the RFC

[RFC] Script only includes - this is 3rd version.
https://wiki.php.net/rfc/script_only_include

Please let me know what you like or dislike.

Thank you.

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

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

Hi,

can I make some minor correction?

Thanks. Dmitry.



On Tue, Feb 10, 2015 at 9:25 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Dmitry,

 On Tue, Feb 10, 2015 at 1:43 PM, Dmitry Stogov dmi...@zend.com wrote:

 On Feb 9, 2015 11:20 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 
  Hi Dmitry and Joe,
 
  On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov dmi...@zend.com wrote:
 
  yes. this may work.
  probably better to put it after extends and implements.
 
 
  Dmitry.
 
  On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins pthre...@pthreads.org
 wrote:
 
  Could this be described as a requirement of the class ?
 
  class Mine
  require(invariant-expr)
  extends Something
  implements Someface {
 
  public function method($param) : return
  require(input-expr),
  return(output-expr) {
 
  }
  }
 
  To avoid invariant keyword maybe.
 
 
  This would work.
  If users have adopted DbC in some way, 'invariant' may be used already.
 
  I see two issues.
 
  Interface works, but most classes are class without interfaces. Then
 users have to repeat
  require()/return() many times to check class state or have to use
 interface for DbC.
 

 In D classes may have invariant constraints. We may use require
 keyword for it. The constraints ineritance rules and order of calls to
 constrains must be the same s in D.

 class Foo {
 private $sum = 0;
 require($this-sum = 0); // invariant constraint will be called
 before and after every method
 function add($n) {
  $this-sum += $n;
 }
 }


 OK. I'll update the RFC.


  Since compiler does not know a method() is for DbC invariant, it will
 be compiled and exists
  in production execution.
 
  Use of interface:
- no additional keyword (pros)
- requires interface for DbC, most classes does not require interface
 (cons)
- if interface is not used, user has to repeat invariant conditions
 over and over (cons)
- requires to define method that should not exist in production (cons)

 I didn't understand you idea.


 Joe's idea was to use Interface for invariant condition grouping.
 If we use your idea, issue is solved.

 class Foo {
 private $sum = 0;
 require($this-sum = 0); // invariant constraint will be called
 before and after every method
 function add($n) {
  $this-sum += $n;
 }
 }

 Ok.

 
  New keyword:
- does not require interface for efficient definition (pros).
- new keyword (cons)
 
  It seems we are better to choose proper keyword for 'invariant'.
 'invariant' is not common, so 'invariant'
  may be good enough choice. Does anyone use 'invariant' as
 function/method/class/constant names?
  If there is better name, suggestion is appreciated.
 
  On place closure call like javascript is not supported in PHP, but
 function works with assert.
 
  ?php
  function foo() { return FALSE; }
  assert(foo());
  ?
  PHP Warning:  assert(): Assertion failed in - on line 3
 
  This wouldn't be changed for require()/return()/invariant()?
 
  We need a switch to change development/production. I'll use
 dbc=On/Off for now.
  If you have any better idea, please let me know. (dbc will be
 INI_SYSTEM)

 Check the expectations RFC. I think, it's going to be 3 state switch,
 zero-cost disable, run-time disable, run-time enable. So, it may be
 INI_ALL, but it won't be possible to switch from/to zero-cost at run-time.


 Ok.

 
  For CLI, there will be no command line switch for dbc. It executes
 script production mode by
  default. If user needs development mode
 
  php -d dbc=1 script.php
 
  should be used.
 
 
  And finally, are we going to allow custom assertion error message? e.g.
 
  require($a  0, 'Parameter $a must be positive number');

 I think, it may be useful.

 Ok. I'll use it.

 
  Since this contract is definition like implements/extends, we may
 not allow
  custom error message. I'll write the RFC not to allow custom error
 messages unless
  you dislike it.
 
  I think we have enough consensus/information to start writing the RFC.
  If I have any concern, I'll ask here.

 Ok, go forward :)

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

 If you would like to change something, please let me know.
 I don't think finished draft at all and I don't mind going back and forth.

 Regards,

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

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi all,

On Tue, Feb 10, 2015 at 5:19 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Use of interface:
   - no additional keyword (pros)
   - requires interface for DbC, most classes does not require interface
 (cons)
   - if interface is not used, user has to repeat invariant conditions over
 and over (cons)
   - requires to define method that should not exist in production (cons)

 New keyword:
   - does not require interface for efficient definition (pros).
   - new keyword (cons)

 It seems we are better to choose proper keyword for 'invariant'.
 'invariant' is not common, so 'invariant'
 may be good enough choice. Does anyone use 'invariant' as
 function/method/class/constant names?
 If there is better name, suggestion is appreciated.


It might be be better to use special method. No keyword, use only reserved
method name __func().
I'll write what I think that are better for PHP in the RFC.
We may discuss anything here to complete the RFC.

Regards,

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

Re: [PHP-DEV] Design by Contract and scalar types ...

[Yasuo Ohgaki]

Hi Lester,

On Tue, Feb 10, 2015 at 4:52 AM, Lester Caine les...@lsces.co.uk wrote:

 Much has been made of adding a class string to handle all the extra
 unicode processing, but I am now thinking that a properly exposed string
 and integer class which has the ability to assign constraint checks does
 make sense. Then use of an integer value on a 32bit platform can error
 when the actual value is too big for the target use. THAT is what strict
 type checking is about!


Scalar may have object capability.

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

IIRC, this wasn't popular, but people's mind may change as time goes by.
It does not cover your requirement, but it may be extended the way it does.

Regards,

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

Re: [PHP-DEV] Dragging the legacy users forward.

[Tony Marston]

Matteo Beccati  wrote in message news:54d883d2.5020...@beccati.com...


On 09/02/2015 10:49, Tony Marston wrote:

But there is a vociferous group who want to change the language in a
revolutionary way instead of an evolutionary way. They want to drop weak
typing and replace it with strict typing, they want to replace a lot of
function names with something more consistent, and they want PHP to
have a purer OO model so that instead of string =
strtoupper($string) you must use $string-toUpper. These
revolutionaries want PHP 7 to be a different language, not an extension
of the existing PHP 5 version.


I don't see any such RFC for PHP7. So it's probably worth if we avoid 
complaining about something that's not being proposed and certainly not 
going to happen.


There may not be an actual RFC for any of these *YET*, but the 
revolutionaries are still out there, plotting and scheming in their dark 
corners. They will be the ones who leap on an innocent-sounding feature and 
silently convert it to something more insidious. Just look at how type 
hinting has been turned into type enforcement as an example.


--
Tony Marston


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

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

Morning Yasuo,

Can you explain what invariant is for ?

I prefer a list of contracts with a single expression, over blocks of
expressions in one contract.
An IDE can just as easy generate a block of code or set of contracts,
so it's really just a matter of how complex it makes the implementation if
you allow any block of code in the contract. I think it does make it
unnecessarily complicated to implement, I can be wrong.

   If there is going to be two rfc's, I will vote no on the annotations
based one, I'd rather no time was wasted on even writing it; Before you
convince anyone that DBC is a good idea you have to convince them
annotations is a good idea, many have tried and failed.

Cheers
Joe

On Mon, Feb 9, 2015 at 10:34 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Dmitry and Joe,

 On Mon, Feb 9, 2015 at 6:01 PM, Dmitry Stogov dmi...@zend.com wrote:

 Usage of return is a good idea.
 The more heads the better result :)


 Less additional reserved word :)
 So I'll use require and return for D like RFC.
 We haven't talk much about invariants. I'll write my idea.

 Current RFC is large enough already, I'll prepare new one.
 We may decide what to do with 2 RFCs.

 We have choices for with block or without block. I prefer with block
 version, since
 assert expression could be messy. With block, IDE may do it's jobs. i.e.
 Hide blocks.

 ==
 Function/Method

 [With block]
 function foo()
 require {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }
 return {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }
 invariant {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }
 {
// body
 }

 _OR_

 [Without block]
 function foo() {
   require(assert-expr, 'msg');
   require(assert-expr, 'msg');
   require(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   return(assert-expr, 'msg');
   return(assert-expr, 'msg');
   return(assert-expr, 'msg');

   // function body
 }


 Currently, following code wouldn't work (PHP 7.0.0-dev)
 --
 assert(function() {return FALSE;}, 'A');
 --

 For block version, which do you prefer, allow any PHP syntax or assert
 only?
 People may use anonymous function  to do fancy jobs anyway if it's
 supported.

 No block version only accepts EXPR obviously, but anonymous function may
 be used with this as well.


 ==
 Class invariants

 [With block]
 class Foo {
   __invariants() {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   }
 }

 _OR_

 [Without block]
 class Foo {
   __construct() {
 invariant(assert-expr, 'msg'); // Only allow in __construct()?
 Allowing invariant.
 invariant(assert-expr, 'msg');
 invariant(assert-expr, 'msg');
   }
 }


 ==
 Global invariant

 I'm not sure if we should have

 function __invariants() {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }

 _OR_

 invariant {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }

 to assert global vars, whole app state, etc. It may be useful for unit
 tests as well as app development.


 I'll start working after I get comment from you.

 Regards,

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

Re: [PHP-DEV] Dragging the legacy users forward.

[Rowan Collins]

Tony Marston wrote on 09/02/2015 10:07:
There may not be an actual RFC for any of these *YET*, but the 
revolutionaries are still out there, plotting and scheming in their 
dark corners. They will be the ones who leap on an innocent-sounding 
feature and silently convert it to something more insidious.


Seriously!? PHP's decision process is wide open to scrutiny, and 
controversial features are nearly always loudly debated, to the point of 
holding up progress at times. The idea that someone could somehow slip a 
critically breaking change into the language *insidiously* is utterly 
ridiculous, and an insult to all the people who work hard honestly 
trying to make the language better for everyone.


Just look at how type hinting has been turned into type 
enforcement as an example. 


OK, I'll look; I'll look at how many hours of debating it's generated, 
and how many different points of view have been put in, and how hard 
Andrea has worked to make the current proposal a compromise which breaks 
the deadlock. This is so completely the opposite of revolutionaries 
plotting in dark corners that the comparison is laughable.


Keep your conspiracy theories for Youtube, and concern yourself with the 
real proposals that are actually happening, all of which are evolutions 
of the language.


Regards,
--
Rowan Collins
[IMSoP]

RE: [PHP-DEV] Re: Annotated PHP 5-7 extension diff

[François Laupretre]

 De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
 Ohgaki

 Basic stuff should be in source. IMO.
 Perhaps, we should use only the Wiki for additional internal stuff from now
 on.

+1. Documenting Zend API in docbook format is unrealistic. The whole ' PHP at 
the Core' chapter should go to the wiki and be replaced with a link.

Another reason is that the manual is supposed to be translated, but this part 
is not, and does not have to be.

Regards

François




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

Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP

[Rowan Collins]

On 9 February 2015 02:16:53 GMT, S.A.N ua.san.a...@gmail.com wrote:
2015-02-09 2:26 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
 On 09/02/2015 00:02, S.A.N wrote:

 You're right, but there is no threading issues.
 One worker synchronously execute requests, but may run parallel many
 workers.


 I'm not sure what you mean by this. I can see 3 ways of handling
incoming
 web requests, as it affects PHP's threading:

 A) The current shared nothing model: the web server may have
multiple
 processes or threads, but each requested is executed in a completely
 separate global scope of PHP.
 B) Each process or thread in the web server spawns an instance of the
 application; the application has a global state within that instance,
and
 startup and shutdown code; the instance is sent multiple requests,
but has
 no way to know if it is getting all the requests, half the requests,
or one
 hundredth of the requests.
 C) The web server executes the application once, which sets up its
global
 state, and then spawns an internal threading model; each request is
sent to
 a worker thread within PHP, which has to synchronise with other
threads in
 order to access any aspect of global state.

 I guess you are suggesting option (B), which is what I was referring
to when
 I said that global state would be arbitrarily shared - if handling
a
 particular request caused any global state to be changed, such as
 registering an error handler, it could affect anything from 0 to 100%
of
 subsequent requests, depending on how the web server is configured.

 The code therefore needs to avoid relying on any such global state at
all,
 which basically restricts you to a subset of the current language.
For it to
 become the default way of running PHP, huge changes would be needed
to adapt
 code to this new model.

 The reason I mentioned threading is that under option (C), migration
becomes
 a bit easier in some ways: you can move some things which are
currently
 global state into an explicitly per-thread state, allowing old
behaviour to
 be emulated; and you can leave other things in synchronized global
state,
 like ini settings, solving the problem of 50% of my threads have a
 different error handler registered.


 Regards,

 --
 Rowan Collins
 [IMSoP]


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


Yes, option (B) is more like.

Let me show in your PHP code, how the option that I like, we have the
actual application work that way in the pecl-event module, we are
satisfied, it is convenient and very fast for PHP.

Yes, I can see it working well for specialised uses - you can simply not use 
those aspects of the language that don't make sense. But for it to be a 
mainstream part of the language, it needs to play nicely with other parts of 
the language, and that's where I see it being a complex and painful change.

Regards,
-- 
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Dragging the legacy users forward.

[Rowan Collins]

Lester Caine wrote on 09/02/2015 01:31:

On 09/02/15 00:05, Rowan Collins wrote:

Some of the new 'styles' of writing things are
going to make things considerably worse for those who are going to have
to maintain this code   in the future.


If you're writing code that you know will be hard to maintain in the
future, you're doing something wrong. If by slavishly following a style
guide you've ended up with a poor architecture, you need a better style
guide, or a better understanding of why those styles are preferred.

Alternatively, I may have misunderstood that sentence, in which case I
apologise in advance.

Something*I*  have been asking for for the last few years IS a better
'style guide' ... There are a growing number of 'styles' and the current
debate is to allow even more! Just about every framework has a different
style of handling database abstraction, and that seems to change every
major version as well. All of my own code is based around ADOdb, but now
it seems THAT is not an acceptable style of code these days.


This is true of pretty much every language under the sun, and isn't 
really relevant to the internals of the language. It's about finding 
books, websites, libraries, and experts who you trust and agree with on 
matters of opinion and prediction. PHP-FIG is working on standardising 
some aspects, but others will always be a matter of fashion and taste.


Regards,
--
Rowan Collins
[IMSoP]

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

[Andrea Faulds]

Hi,

 On 9 Feb 2015, at 03:48, Zeev Suraski z...@zend.com wrote:
 
 A - has pretty much everybody agreeing with is a good idea.  Nobody objects 
 to it.  It's under consensus.

This isn't true. I've explained why it isn't true several times. Maybe you are 
suffering from confirmation bias or something, but there is no such 
consensus. Quite a few internals contributors liked v0.1. Quite a few didn't. 
I've gone and evidenced this before in replies sent directly to you. 

In addition, the reaction from the wider community was largely negative.

 B - has a large number of people thinking it's alien to PHP, and has many 
 people objecting to it.

B also has a large number of supporters because it is a pragmatic compromise.

A also had a large number of detractors.

 The vote is on A+B.

No it isn't.

You are claiming, as I understand it, that:


* Weak typing has consensus (it doesn't)
* Strict typing is entirely controversial (it has many supporters, however)
* This proposal including both somehow nullifies the argument that weak typing 
lacks consensus (it doesn't - someone is free to oppose the addition of 
something in isolation yet support its addition in combination)

The truth of the matter is this. There are at least two approaches to scalar 
type hint behaviour: weak and strict. Both are highly controversial. The 
addition of either exclusively, is controversial. The addition of both 
together, is controversial. The addition of stricter weak typing, is 
controversial. The issue of scalar type hints is highly controversial in 
general for these reasons.

There is no consensus whatsoever. To suggest there is would be to grossly 
exaggerate.

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

RE: [PHP-DEV] scalar type hints

[François Laupretre]

 De : Pierre Joye [mailto:pierre@gmail.com]

  However, DbC is coming close!
 
  DbC brings much more flexibility, strict/loose constraints, performance,
  security, better documentation and more.
  DbC suitable for weakly typed PHP perfectly.
 
  Therefore, I'm holding my vote now.
  I hope everyone have an attention to DbC and consider thoughtfully.
 
 Imho they are totally different things.

You're right. That's two different things in the way they are implemented. But 
they are also closely related because both approaches propose an element of 
solution to similar needs: reduce coding errors.

Then, depending on their own position about strict types, people will consider 
it as just a complement, or as a whole alternative. I agree on one thing, we 
mustn't mix both discussions :)

Cheers

François


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

Re: [PHP-DEV] Syntactical change to Scalar Type Hints RFC

[Rowan Collins]

Pierre Joye wrote on 09/02/2015 00:05:

On Mon, Feb 9, 2015 at 6:30 AM, Rowan Collins rowan.coll...@gmail.com wrote:

On 08/02/2015 20:33, Zeev Suraski wrote:

FWIW, while I think strict types - stricter than even strict languages -
don't belong in PHP, this syntax is clearly a step up from declare(),
which
was definitely not intended for this purpose.


I'm kind of intrigued what purpose it *was* intended for. I've always found
it a rather odd part of the language, but this seems as logical a use for it
as any.

For years, it had exactly one execution directive, which worked in concert
with a runtime event handler (ticks=N + register_tick_function). In PHP 5.3,
a completely unrelated directive was added, to specify the encoding of the
file (something that more obviously has to be detected by the compiler).

Was there an original idea of what it would be used for that never came to
fruition? Or is there something I'm missing that connects ticks and
encoding, but excludes strict_types?

Both are being done at compile time and modify how a file is compiled.
So no, I do not agree with runtime here, while one directive is
being used at runtime.


I didn't say it was runtime, I said it worked in concert with runtime 
code. My point was that declare(encoding) is something purely internal 
to the compiler, affecting how it parses the file, whereas 
declare(ticks) is using the compiler to change the actual execution of 
the code, which makes them feel very different in effect.


It's quite hard to generalise from those two examples to any real 
vision of declare()'s purpose, so I was genuinely curious what that 
vision was.


Regards,
--
Rowan Collins
[IMSoP]


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

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

[Andrea Faulds]

Hi,

 On 9 Feb 2015, at 08:04, Dmitry Stogov dmi...@zend.com wrote:
 
 this is more or less true. :(
 The proposal is presented in an unfair way to include strict typing without
 the ability to vote for weak types only.

Oddly, nobody seems to complain that it's unfair if I side with the weak typing 
camp, despite that being equally unfair.

 Despite of semantic arguments, the implementation is a bit immature and
 introduces slowdown for any code without type hints.

The implementation could do with improvement, this is true. However I suspect 
any slowdown is minor at best, and this could be dealt with in future. The RFC 
is more about the language change than the implementation.

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

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

RE: [PHP-DEV] Syntactical change to Scalar Type Hints RFC

[François Laupretre]

 De : Rowan Collins [mailto:rowan.coll...@gmail.com]

  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.

+1. We cannot allow a keyword (yes, it IS a reserved keyword) in this location 
and say Oh, that's just an exception for strict type checking, but no one has 
the right to do the same, except Andrea if she needs it again in the future..

If we extend the syntax, we must establish rules for keywords on the same line 
as '?php'. IMO, it would apply to the code block, not to the whole file, or 
you need to add constraints that go too far (disable '?' and the like). 
Unfortunately, the BC break would probably make such an RFC still more 
problematic than strict typing.

Another concern is that 'strict', while elegant, is ambiguous. I guess most 
people would think it enables E_STRICT, which I would intuitively believe.

Cheers

François


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

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

[Lester Caine]

On 09/02/15 10:44, Andrea Faulds wrote:
 There is no consensus whatsoever. To suggest there is would be to grossly 
 exaggerate.

I am just happy that to force change through a 2/3rds majority is
required. If there was a consensus then the debate would not have been
so extensive, but while the continuing chant of 'you don't have to use
it' prevails, we end up with a lot of additional overheads just to keep
a small number of users happy.

In the case of this vote, the vote itself IS flawed as two different
additions ARE being pushed together, and personally I feel that the yes
vote IS being distorted by those who want weak typing and could not care
less about strong typing. That neither of the proposed solutions
actually provide a complete solution for either camp is a shame.

I do understand why many of these extras can't simply be user selectable
extensions, but just how many of the 'core' modules are actually needed
for a basic PHP server. Yes I need 'typing' but I need a version that
handles the types I am using not some rather limited subset, and
improvements in PHP7 has increased the need for a proper typing system
which scalar type hints does nothing to address :(

-- 
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] Design by Contract

[Dmitry Stogov]

yes. this may work.
probably better to put it after extends and implements.

Dmitry.

On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins pthre...@pthreads.org wrote:

 Could this be described as a requirement of the class ?

 class Mine
 require(invariant-expr)
 extends Something
 implements Someface {

 public function method($param) : return
 require(input-expr),
 return(output-expr) {

 }
 }

 To avoid invariant keyword maybe.

 Cheers
 Joe

 On Mon, Feb 9, 2015 at 11:05 AM, Dmitry Stogov dmi...@zend.com wrote:

 invariant is for classes only. It should be called before and/or after
 each method to check object consistency.

 syntax with expressions may work if we put constraints before the
 function body .

 function foo($a int): int
 require(expr1)
 require(expr2, msg)
 return(expr3)
 {
 }

 Yasuo, I would suggest to describe both syntax options.

 Thanks. Dmitry.

 On Mon, Feb 9, 2015 at 1:46 PM, Joe Watkins pthre...@pthreads.org
 wrote:

 Morning Yasuo,

 Can you explain what invariant is for ?

 I prefer a list of contracts with a single expression, over blocks
 of expressions in one contract.
 An IDE can just as easy generate a block of code or set of
 contracts, so it's really just a matter of how complex it makes the
 implementation if you allow any block of code in the contract. I think it
 does make it unnecessarily complicated to implement, I can be wrong.

If there is going to be two rfc's, I will vote no on the annotations
 based one, I'd rather no time was wasted on even writing it; Before you
 convince anyone that DBC is a good idea you have to convince them
 annotations is a good idea, many have tried and failed.

 Cheers
 Joe

 On Mon, Feb 9, 2015 at 10:34 AM, Yasuo Ohgaki yohg...@ohgaki.net
 wrote:

 Hi Dmitry and Joe,

 On Mon, Feb 9, 2015 at 6:01 PM, Dmitry Stogov dmi...@zend.com wrote:

 Usage of return is a good idea.
 The more heads the better result :)


 Less additional reserved word :)
 So I'll use require and return for D like RFC.
 We haven't talk much about invariants. I'll write my idea.

 Current RFC is large enough already, I'll prepare new one.
 We may decide what to do with 2 RFCs.

 We have choices for with block or without block. I prefer with block
 version, since
 assert expression could be messy. With block, IDE may do it's jobs.
 i.e. Hide blocks.

 ==
 Function/Method

 [With block]
 function foo()
 require {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }
 return {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }
 invariant {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }
 {
// body
 }

 _OR_

 [Without block]
 function foo() {
   require(assert-expr, 'msg');
   require(assert-expr, 'msg');
   require(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   return(assert-expr, 'msg');
   return(assert-expr, 'msg');
   return(assert-expr, 'msg');

   // function body
 }


 Currently, following code wouldn't work (PHP 7.0.0-dev)
 --
 assert(function() {return FALSE;}, 'A');
 --

 For block version, which do you prefer, allow any PHP syntax or assert
 only?
 People may use anonymous function  to do fancy jobs anyway if it's
 supported.

 No block version only accepts EXPR obviously, but anonymous function
 may
 be used with this as well.


 ==
 Class invariants

 [With block]
 class Foo {
   __invariants() {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   }
 }

 _OR_

 [Without block]
 class Foo {
   __construct() {
 invariant(assert-expr, 'msg'); // Only allow in __construct()?
 Allowing invariant.
 invariant(assert-expr, 'msg');
 invariant(assert-expr, 'msg');
   }
 }


 ==
 Global invariant

 I'm not sure if we should have

 function __invariants() {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }

 _OR_

 invariant {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }

 to assert global vars, whole app state, etc. It may be useful for unit
 tests as well as app development.


 I'll start working after I get comment from you.

 Regards,

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

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

Yeah, after 

On Mon, Feb 9, 2015 at 11:27 AM, Dmitry Stogov dmi...@zend.com wrote:

 yes. this may work.
 probably better to put it after extends and implements.

 Dmitry.

 On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins pthre...@pthreads.org wrote:

 Could this be described as a requirement of the class ?

 class Mine
 require(invariant-expr)
 extends Something
 implements Someface {

 public function method($param) : return
 require(input-expr),
 return(output-expr) {

 }
 }

 To avoid invariant keyword maybe.

 Cheers
 Joe

 On Mon, Feb 9, 2015 at 11:05 AM, Dmitry Stogov dmi...@zend.com wrote:

 invariant is for classes only. It should be called before and/or after
 each method to check object consistency.

 syntax with expressions may work if we put constraints before the
 function body .

 function foo($a int): int
 require(expr1)
 require(expr2, msg)
 return(expr3)
 {
 }

 Yasuo, I would suggest to describe both syntax options.

 Thanks. Dmitry.

 On Mon, Feb 9, 2015 at 1:46 PM, Joe Watkins pthre...@pthreads.org
 wrote:

 Morning Yasuo,

 Can you explain what invariant is for ?

 I prefer a list of contracts with a single expression, over blocks
 of expressions in one contract.
 An IDE can just as easy generate a block of code or set of
 contracts, so it's really just a matter of how complex it makes the
 implementation if you allow any block of code in the contract. I think it
 does make it unnecessarily complicated to implement, I can be wrong.

If there is going to be two rfc's, I will vote no on the annotations
 based one, I'd rather no time was wasted on even writing it; Before you
 convince anyone that DBC is a good idea you have to convince them
 annotations is a good idea, many have tried and failed.

 Cheers
 Joe

 On Mon, Feb 9, 2015 at 10:34 AM, Yasuo Ohgaki yohg...@ohgaki.net
 wrote:

 Hi Dmitry and Joe,

 On Mon, Feb 9, 2015 at 6:01 PM, Dmitry Stogov dmi...@zend.com wrote:

 Usage of return is a good idea.
 The more heads the better result :)


 Less additional reserved word :)
 So I'll use require and return for D like RFC.
 We haven't talk much about invariants. I'll write my idea.

 Current RFC is large enough already, I'll prepare new one.
 We may decide what to do with 2 RFCs.

 We have choices for with block or without block. I prefer with block
 version, since
 assert expression could be messy. With block, IDE may do it's jobs.
 i.e. Hide blocks.

 ==
 Function/Method

 [With block]
 function foo()
 require {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }
 return {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }
 invariant {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }
 {
// body
 }

 _OR_

 [Without block]
 function foo() {
   require(assert-expr, 'msg');
   require(assert-expr, 'msg');
   require(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   return(assert-expr, 'msg');
   return(assert-expr, 'msg');
   return(assert-expr, 'msg');

   // function body
 }


 Currently, following code wouldn't work (PHP 7.0.0-dev)
 --
 assert(function() {return FALSE;}, 'A');
 --

 For block version, which do you prefer, allow any PHP syntax or assert
 only?
 People may use anonymous function  to do fancy jobs anyway if it's
 supported.

 No block version only accepts EXPR obviously, but anonymous function
 may
 be used with this as well.


 ==
 Class invariants

 [With block]
 class Foo {
   __invariants() {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   }
 }

 _OR_

 [Without block]
 class Foo {
   __construct() {
 invariant(assert-expr, 'msg'); // Only allow in __construct()?
 Allowing invariant.
 invariant(assert-expr, 'msg');
 invariant(assert-expr, 'msg');
   }
 }


 ==
 Global invariant

 I'm not sure if we should have

 function __invariants() {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }

 _OR_

 invariant {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }

 to assert global vars, whole app state, etc. It may be useful for unit
 tests as well as app development.


 I'll start working after I get comment from you.

 Regards,

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

Re: [PHP-DEV] new json, push generated file?

[Pierre Joye]

On Feb 9, 2015 4:46 PM, Jakub Zelenka bu...@php.net wrote:

 On Mon, Feb 9, 2015 at 9:18 AM, Anatol Belski anatol@belski.net
wrote:

 Hi,

 On Mon, February 9, 2015 07:33, Xinchen Hui wrote:
  Hey:
 
 
 
 
  On Mon, Feb 9, 2015 at 1:44 PM, Pierre Joye pierre@gmail.com
wrote:
 
  On Mon, Feb 9, 2015 at 11:10 AM, Xinchen Hui larue...@php.net wrote:
 
  Hey:
 
 
  On Mon, Feb 9, 2015 at 10:40 AM, Pierre Joye pierre@gmail.com
  wrote:
 
  hi,
 
  Should we push json_parser.tab.c? Which is generated (re2c), just
  like what is done in date or other?
 
  I think we should, and also use a better name...(.tab.c?)
 
 
  that too :)
  simply, json_parser.c is good
 
  something like: https://gist.github.com/laruence/f33903266cec737088aa
 
 I'd be for applying this as well. Also, just added the generation calls
to
 config.w32, but actulaly a checked in file were much simpler to handle.

 Regards

 Anatol


 Hi,

 The re2c generated files are pushed (see
https://github.com/php/php-src/blob/master/ext/json/json_scanner.c ). The
json_parser.tab.c is a BISON generated file. I haven't pushed that file
because we don't have bison generated files in repo (e.g.
zend_language_parser.c). I'm actually for pushing that file as well but
then we should probably push zend_language_parser.c too. Thoughts?

 The name .tab.c is a standard name for bison files ( see last paragraph
http://www.gnu.org/software/bison/manual/html_node/Rpcalc-Generate.html#Rpcalc-Generate
). I think that it can be changed but not sure if it makes much sense. The
.tab.c says that it's a C file with parsing tables...

I still think it is better to have this file applied. It is not like they
will change every 2nd day.

 Cheers

 Jakub

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

[Pascal MARTIN]

Le 05/02/2015 21:14, Andrea Faulds a écrit :

At long last, I’m going to put the RFC to a vote. It’s been long enough - I 
don’t think there needs to be, or will be, much further discussion.

I’d like to make sure that everyone voting understands the RFC fully. Please 
read the RFC in full: the details are important. And if  anyone has any 
questions or uncertainties, please ask them before voting. I am very happy to 
answer them.

I would urge everyone who wants type hints to vote for this RFC. It is not a 
perfect solution, but there can be no perfect solution to this issue. However, 
I think it is better than most of the alternatives suggested thus far - see the 
rationale section, and previous discussions. Crucially, this RFC would keep PHP 
a weakly-typed language, and not force either strict typing, nor weak typing, 
on anyone who does not want it. It would allow the addition of type hints to 
existing codebases. It would not create a situation where userland functions 
are strict yet internal functions are not, because the strict mode affects 
both. I’ve tested the implementation myself on my own code, and it worked well, 
providing benefits other proposals would not have given (see my previous post 
about my experiences).



Hi,

Just to let you know, I've written a post about this RFC on my blog, 
trying to present what it brings to the table and to explain why I like it:


http://blog.pascal-martin.fr/post/in-favor-of-rfc-scalar-type-hints.html

Maybe another way of presenting things might help some people here to 
decide whether or not they think this RFC is helpful.


Even if I've published this earlier today, I've written it between 
Thursday and Friday, so it doesn't really take into account the new 
ideas (new syntax propositions) that have been posted since.


Please note this is *my* personal opinion, and doesn't necessarily 
reflect the opinion of any organization I am affiliated with.


Pascal.

--
Pascal MARTIN
http://blog.pascal-martin.fr
@pascal_martin

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

Re: [PHP-DEV] Dragging the legacy users forward.

[Matteo Beccati]

On 09/02/2015 11:07, Tony Marston wrote:

There may not be an actual RFC for any of these *YET*, but the
revolutionaries are still out there, plotting and scheming in their dark
corners. They will be the ones who leap on an innocent-sounding feature
and silently convert it to something more insidious. Just look at how
type hinting has been turned into type enforcement as an example.


Only if you're willing to use it. But with the current proposal, no 3rd 
party library developer can actually force you to use strict typing if 
you don't want to. What's insidious about it?


That's the reason I voted yes, even though I dislike the idea of 
strict scalar type hinting in PHP.



Cheers
--
Matteo Beccati

Development  Consulting - http://www.beccati.com/

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

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Dmitry and Joe,

On Mon, Feb 9, 2015 at 6:01 PM, Dmitry Stogov dmi...@zend.com wrote:

 Usage of return is a good idea.
 The more heads the better result :)


Less additional reserved word :)
So I'll use require and return for D like RFC.
We haven't talk much about invariants. I'll write my idea.

Current RFC is large enough already, I'll prepare new one.
We may decide what to do with 2 RFCs.

We have choices for with block or without block. I prefer with block
version, since
assert expression could be messy. With block, IDE may do it's jobs. i.e.
Hide blocks.

==
Function/Method

[With block]
function foo()
require {
  assert(assert-expr, 'msg');
  assert(assert-expr, 'msg');
  assert(assert-expr, 'msg');
}
return {
  assert(assert-expr, 'msg');
  assert(assert-expr, 'msg');
  assert(assert-expr, 'msg');
}
invariant {
  assert(assert-expr, 'msg');
  assert(assert-expr, 'msg');
  assert(assert-expr, 'msg');
}
{
   // body
}

_OR_

[Without block]
function foo() {
  require(assert-expr, 'msg');
  require(assert-expr, 'msg');
  require(assert-expr, 'msg');
  invariant(assert-expr, 'msg');
  invariant(assert-expr, 'msg');
  invariant(assert-expr, 'msg');
  return(assert-expr, 'msg');
  return(assert-expr, 'msg');
  return(assert-expr, 'msg');

  // function body
}


Currently, following code wouldn't work (PHP 7.0.0-dev)
--
assert(function() {return FALSE;}, 'A');
--

For block version, which do you prefer, allow any PHP syntax or assert
only?
People may use anonymous function  to do fancy jobs anyway if it's
supported.

No block version only accepts EXPR obviously, but anonymous function may
be used with this as well.


==
Class invariants

[With block]
class Foo {
  __invariants() {
  assert(assert-expr, 'msg');
  assert(assert-expr, 'msg');
  assert(assert-expr, 'msg');
  }
}

_OR_

[Without block]
class Foo {
  __construct() {
invariant(assert-expr, 'msg'); // Only allow in __construct()? Allowing
invariant.
invariant(assert-expr, 'msg');
invariant(assert-expr, 'msg');
  }
}


==
Global invariant

I'm not sure if we should have

function __invariants() {
  assert(assert-expr, 'msg');
  assert(assert-expr, 'msg');
  assert(assert-expr, 'msg');
}

_OR_

invariant {
  assert(assert-expr, 'msg');
  assert(assert-expr, 'msg');
  assert(assert-expr, 'msg');
}

to assert global vars, whole app state, etc. It may be useful for unit
tests as well as app development.


I'll start working after I get comment from you.

Regards,

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

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

HI Dmitry,

On Mon, Feb 9, 2015 at 7:34 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:


 [Without block]
 function foo() {
   require(assert-expr, 'msg');
   require(assert-expr, 'msg');
   require(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   return(assert-expr, 'msg');
   return(assert-expr, 'msg');
   return(assert-expr, 'msg');

   // function body
 }



OOPS. Without block cannot work ;)
I should have notice while I'm writing.

I'll go with with block. If you find any other issues, please let me know.

Regards,

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

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

invariant is for classes only. It should be called before and/or after each
method to check object consistency.

syntax with expressions may work if we put constraints before the function
body .

function foo($a int): int
require(expr1)
require(expr2, msg)
return(expr3)
{
}

Yasuo, I would suggest to describe both syntax options.

Thanks. Dmitry.

On Mon, Feb 9, 2015 at 1:46 PM, Joe Watkins pthre...@pthreads.org wrote:

 Morning Yasuo,

 Can you explain what invariant is for ?

 I prefer a list of contracts with a single expression, over blocks of
 expressions in one contract.
 An IDE can just as easy generate a block of code or set of contracts,
 so it's really just a matter of how complex it makes the implementation if
 you allow any block of code in the contract. I think it does make it
 unnecessarily complicated to implement, I can be wrong.

If there is going to be two rfc's, I will vote no on the annotations
 based one, I'd rather no time was wasted on even writing it; Before you
 convince anyone that DBC is a good idea you have to convince them
 annotations is a good idea, many have tried and failed.

 Cheers
 Joe

 On Mon, Feb 9, 2015 at 10:34 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Dmitry and Joe,

 On Mon, Feb 9, 2015 at 6:01 PM, Dmitry Stogov dmi...@zend.com wrote:

 Usage of return is a good idea.
 The more heads the better result :)


 Less additional reserved word :)
 So I'll use require and return for D like RFC.
 We haven't talk much about invariants. I'll write my idea.

 Current RFC is large enough already, I'll prepare new one.
 We may decide what to do with 2 RFCs.

 We have choices for with block or without block. I prefer with block
 version, since
 assert expression could be messy. With block, IDE may do it's jobs. i.e.
 Hide blocks.

 ==
 Function/Method

 [With block]
 function foo()
 require {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }
 return {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }
 invariant {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }
 {
// body
 }

 _OR_

 [Without block]
 function foo() {
   require(assert-expr, 'msg');
   require(assert-expr, 'msg');
   require(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   invariant(assert-expr, 'msg');
   return(assert-expr, 'msg');
   return(assert-expr, 'msg');
   return(assert-expr, 'msg');

   // function body
 }


 Currently, following code wouldn't work (PHP 7.0.0-dev)
 --
 assert(function() {return FALSE;}, 'A');
 --

 For block version, which do you prefer, allow any PHP syntax or assert
 only?
 People may use anonymous function  to do fancy jobs anyway if it's
 supported.

 No block version only accepts EXPR obviously, but anonymous function may
 be used with this as well.


 ==
 Class invariants

 [With block]
 class Foo {
   __invariants() {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   }
 }

 _OR_

 [Without block]
 class Foo {
   __construct() {
 invariant(assert-expr, 'msg'); // Only allow in __construct()?
 Allowing invariant.
 invariant(assert-expr, 'msg');
 invariant(assert-expr, 'msg');
   }
 }


 ==
 Global invariant

 I'm not sure if we should have

 function __invariants() {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }

 _OR_

 invariant {
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
   assert(assert-expr, 'msg');
 }

 to assert global vars, whole app state, etc. It may be useful for unit
 tests as well as app development.


 I'll start working after I get comment from you.

 Regards,

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

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

[Andi Gutmans]

 On Feb 7, 2015, at 7:52 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 
 On 02/07/2015 09:51 PM, Andrea Faulds wrote:
 tan(1);
 echo strstr(test, est, 1);
 
 Banning int-float and float-int is both a pain point and sometimes a 
 life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you 
 discover if your ints floats would be silently truncated (as I did with 
 PictoSwap).
 
 I wouldn’t say that int-string not working is a problem, though. Seeing 
 something like strstr(“test”, “est”, 1); is rather confusing. Looking at it, 
 I’d think the third parameter is some sort of number for you to want to pass 
 an integer to it. If I want a string, I’ll use one.
 
 This isn't int-string. This is int-boolean. The 3rd arg to strstr() is
 a boolean and passing 1 instead of true makes it blow up. It is very
 very common for people to pass 0 or 1 in place of true/false to all
 sorts of things in PHP.


Thanks for those relevant examples.
I think it’s also worth emphasizing that in C people frequently work around 
this by forcing casts. The value of strict typing diminishes quickly and the 
code ends up being less readable.

I think in PHP this is going to be even more so due to the reasons Rasmus 
states. We have *a lot* of places like this which will lead to unnatural acts 
and code which is no more strict than it was before (just not as pretty).

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

Re: [PHP-DEV] Syntactical change to Scalar Type Hints RFC

[Rowan Collins]

Andrea Faulds wrote on 09/02/2015 00:05:

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.


Thinking about it, declare(encoding) already disallows scope anyway, so 
we wouldn't even be introducing something new: Fatal error: Encoding 
declaration pragma must be the very first statement in the script.



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

Re: [PHP-DEV] Annotated PHP 5-7 extension diff

[Lester Caine]

On 09/02/15 15:03, Jan Ehrhardt wrote:
 Despite the extensive list of changes, imagick does not compile anymore
 with the current PHP7 git head (Win32 VC11).

Jan ... try the latest code from Dan ...
Just got both php7 and php5.6.5 running including a populated phpinfo on
each so I'm moving on ...

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

[PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions

[Anatol Belski]

Hi,

the voting on the removals in PHP7 in hereby finished. The results are


item   yes:no

sapi/aolserver 32:0
sapi/apache32:0
sapi/apache_hooks  31:0
sapi/apache2filter 23:1
sapi/caudium   30:0
sapi/continuity28:0
sapi/isapi 28:0
sapi/milter10:9
sapi/phttpd26:0
sapi/pi3web24:0
sapi/roxen 23:0
sapi/thttpd25:0
sapi/tux   25:0
sapi/webjames  25:0
ext/imap   14:19
ext/mcrypt 15:18
ext/mssql  17:13
ext/pdo_dblib  4:18
ext/sybase_ct  17:1

As most of the items are considered to be removed, the ones to stay
untouched by the 50%+1 requirement are

ext/imap
ext/mcrypt
ext/pdo_dblib

I'm going to implement and tag the changes considered ASAP. Regarding the
stuff to considered to be removed from the core - if there are some
supporters, the sources will be made available in the git tag. They can be
anytime ported to PHP7 and possibly resurrected.

Regards

Anatol




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

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

[Michael Wallner]

On 08/02/15 23:25, Stanislav Malyshev wrote:

 Youself said that HTTP is a stateless protocol, so how would a
 connection in an unclean state look like in your opinion?
 
 Connection and protocol are different things. In connection, you could
 be in the middle of the protocol - i.e. sending headers, sending body,
 receiving headers, receiving body - and these are different states.
 
 Curl caches connections the servers are fine with keeping alive, and I
 cache curl handles grouped by the id you pass to the client constructor
 and the authority of the url, that's all, nothing spooky.
 
 Caching connections within the same request and reusing them is not
 spooky, but caching them long term, across requests, across security
 domains, for extended time - is spooky.
 


Everything you said also applies to database connections; there are even
database services that work over HTTP.

I'm still having a fairly hard time groking the issue at hand, sorry.


-- 
Regards,
Mike

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

RE: [PHP-DEV] scalar type hints

[Pierre Joye]

On Feb 9, 2015 6:07 PM, François Laupretre franc...@tekwire.net wrote:

  De : Pierre Joye [mailto:pierre@gmail.com]
 
   However, DbC is coming close!
  
   DbC brings much more flexibility, strict/loose constraints,
performance,
   security, better documentation and more.
   DbC suitable for weakly typed PHP perfectly.
  
   Therefore, I'm holding my vote now.
   I hope everyone have an attention to DbC and consider thoughtfully.
 
  Imho they are totally different things.

 You're right. That's two different things in the way they are
implemented. But they are also closely related because both approaches
propose an element of solution to similar needs: reduce coding errors.

 Then, depending on their own position about strict types, people will
consider it as just a complement, or as a whole alternative. I agree on one
thing, we mustn't mix both discussions :)

It is not what I am saying.

Let me try with a fictional example.

Let say we have a RFC about adding support to comments in code. Yes, simple
comments.

Now what has been said here is that he suspends his vote because there is
other working on adding phpdoc. And comparing DbC with type hinting is
light years different.

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

On Mon, Feb 9, 2015 at 3:57 PM, François Laupretre franc...@tekwire.net
wrote:

 Hi Dmitry,

  De : Dmitry Stogov [mailto:dmi...@zend.com]
  Envoyé : lundi 9 février 2015 12:05
  À : Joe Watkins
  Cc : Yasuo Ohgaki; Stanislav Malyshev; PHP Internals
  Objet : Re: [PHP-DEV] Design by Contract
 
  invariant is for classes only. It should be called before and/or after
 each
  method to check object consistency.
 
  syntax with expressions may work if we put constraints before the
 function
  body .
 
  function foo($a int): int
  require(expr1)
  require(expr2, msg)
  return(expr3)
  {
  }

 I understand you're defining an implementation based on assertions only,
 despite the fact that 'require' and 'return' are very ambiguous choices IMO.

 Did you take into account that, in many cases, this would revert to strict
 type checking, due to the way is_xxx() functions are working ?

 If someone writes 'function tan($op) / require (is_float($op));' will he
 expect tan(1) to be rejected ? (we're back to Rasmus' complaint).


You'll get exactly what you write in constraint, no any predefined
semantic, no need to learn predefined rules.



 The same with is_int() and others, they're all based on zval types. Only
 is_numeric() is smarter and allows specifying a 'number' in the PHP way.
 Unfortunately, these functions are wrong as they don't fit with the way
 people are used to consider types in PHP. So, no easy way to say you can
 accept 1 or 1.0, let alone 1.

 That's why my proposal features assertions AND 'smart' argument types.
 Actually, types are more important than assertions because that's what
 people will use first. Primary use for assertions will be checking
 conditions between args. The same for properties and return type. Actually,
 I would say that most phpdoc-annotated code already contains most DbC
 constraints it needs. We just need to formalize and use them.


I think, people will use type hinting first (in a way they'll be
implemented in PHP-7).

Thanks. Dmitry.


 As others already said here, be it for type checking or DbC, we need a
 mechanism to interpret types the 'PHP' way, something between PHP
 permissive type juggling and strict zval-based typing. That's what I tried
 to define.


 I understand the prevention against inserting PHP code in doc comments
 and, if I was designing the language from scratch, I wouldn't use such a
 design. But, considering every aspects of the problem, I still think it's
 the best compromise to add the feature.

 Regards

 François

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

[Michael Wallner]

On 08/02/15 23:25, Stanislav Malyshev wrote:
 Hi!
 
 Are you saying performance is not the reason we use persistent handles?
 
 It is, for databases where connection setup is expensive. Even then
 persistent handles are not always the best solution. But with DB, you
 routinely connect to one service, with one set of credentials, and need
 this connection constantly. With HTTP, it is rarely the case that you
 want to maintain the connection to the same service for an extended time
 (like hours or even days).

The server dictates this ony you anyway. It's only leveraging Keep-Alive
and it is the server that's ultimately deciding whether it allows a
connection to stay open for a limited amount of time.

 
 Stas, I really don't understand what's the issue here for you.
 
 The issue is that I think maintaining long-time persistent HTTP
 connections (I do not mean keepalive connection that serves a number of
 requests within the context of one workload, like browser does) is not a
 good idea, in fact it looks suspiciously like a DOS since many HTTP
 servers, including Apache, are not equipped properly to handle such
 model. While there may be corner cases where it may be useful,
 encouraging the practice looks like a mistake to me.

There won't be any forced-open connections. Connections won't be cached
if the server doesn't support or allow Keep-Alive. Utilizing Keep-Alive
is not encouraged per-se, it's just an offer, because it is not enabled
by default.

-- 
Regards,
Mike

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

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

[Sebastian Bergmann]

Am 07.02.2015 um 02:08 schrieb Sebastian Bergmann:
 After reading your email, Nikita, I deleted my vote (it was no before).
 I will review the RFC again, with your arguments (and others) in mind
 and maybe I'll come to a different conclusion.

 I have voted (no) again.

 I still think that if we add support for scalars in type declarations
 then the corresponding check must be strict. But since that strictness
 does not align with the spirit of PHP I much rather have no support
 for scalars than one that is not strict.

 Maybe built-in classes such as String, Integer, Float, Boolean that know
 how convert themselves to the corresponding scalar type are a viable
 approach that is worth exploring.

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

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[André Rømcke]

 
 On 02 Feb 2015, at 17:35 , Derick Rethans der...@php.net wrote:
 
 On Mon, 2 Feb 2015, Dmitry Stogov wrote:
 
 As I already told, in my opinion, version 0.1 was the perfect solution that
 fit into PHP semantic very well.
 
 declare(strict_types=1); - is really weird solution.
 It changes type hinting behavior per file scope, so, just to try strict
 type hinting in a big project, people will have to change every single PHP
 file.


declare() might not be beautiful, but it is pragmatic as it already exists.
As for full project switch, can’t we easily do a followup RFC with a command 
line flag/ini setting to run unit tests in strict mode for instance?

 
 THis is why I believe it makes more sense to have this switch on the 
 callee side, instead of on the calling side.


I’m not sure I see why that would make more sense.
On the callee side what you get is strictly what you asked for anyway, no 
matter what mode on the calling side. 

This is the true beauty of what Andrea has come up with here, allowing weak PHP 
like forgiveness to co-exists with opt in for strict behavior.


Best,
André

Re: [PHP-DEV] new json, push generated file?

[Jakub Zelenka]

On Mon, Feb 9, 2015 at 1:55 PM, Pierre Joye pierre@gmail.com wrote:

 I still think it is better to have this file applied. It is not like they
 will change every 2nd day.

Hi,

I think that I might have solution for this and also for my another build
problem which is re2c version.

I have just created a PR where I tried to explain everything:

https://github.com/php/php-src/pull/1072

Basically ti adds all sources but allows to regenerate them only if the
options --enable-json-filegen is set (more details are in the description).

The config changes are just for Linux as I'm not sure how to do it on win
and if it's even needed (if someone will send any patches to json scanner
or parser and needs to generate them automatically).

I'll keep the PR open for a week or so and if there are no objection, I
would like merge it. I'm also open changing the name of the option and will
be glad for any config.m4 related comments and reviews.

Cheers

Jakub