Am 10.02.2015 08:25 schrieb "Yasuo Ohgaki" :
>
>> 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
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 add
Hi Joe,
On Tue, Feb 10, 2015 at 4:31 PM, Joe Watkins 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
Am 10.02.2015 08:08 schrieb "Yasuo Ohgaki" :
>
> 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
altern
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 wrote:
> Hi Dmitry,
>
> On Tue, Feb 10, 2015 at 4:21 PM, Dmitry Stogo
Hi Dmitry,
On Tue, Feb 10, 2015 at 4:21 PM, Dmitry Stogov 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 h
> 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,
Hi Patrick,
On Tue, Feb 10, 2015 at 4:06 PM, Patrick Schaaf wrote:
> Am 10.02.2015 07:25 schrieb "Yasuo Ohgaki" :
> >
> > 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 invariant
On Tue, Feb 10, 2015 at 10:06 AM, Patrick Schaaf wrote:
> Am 10.02.2015 07:25 schrieb "Yasuo Ohgaki" :
> >
> > 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 wil
Hi Joe,
On Tue, Feb 10, 2015 at 3:59 PM, Joe Watkins 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 th
Am 10.02.2015 07:25 schrieb "Yasuo Ohgaki" :
>
> 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?
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 wrote:
> I'm not sure we can always enforce invariant contracts ...
>
> Evaluating invariant expressions on entry and exit is not enough, since a
>
Hi
On Tue, Feb 10, 2015 at 3:49 PM, Dmitry Stogov wrote:
>
> can I make some minor correction?
Sure. I'm done now.
I would not touch at least few hours.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
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 Tu
Hi,
can I make some minor correction?
Thanks. Dmitry.
On Tue, Feb 10, 2015 at 9:25 AM, Yasuo Ohgaki wrote:
> Hi Dmitry,
>
> On Tue, Feb 10, 2015 at 1:43 PM, Dmitry Stogov wrote:
>
>> On Feb 9, 2015 11:20 PM, "Yasuo Ohgaki" wrote:
>> >
>> > Hi Dmitry and Joe,
>> >
>> > On Mon, Feb 9, 2015 a
> 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 wrote:
> Hi Joe,
>
> On Tue, Feb 10, 2015 at 3:16 PM, Joe Wat
Hi Joe,
On Tue, Feb 10, 2015 at 3:16 PM, Joe Watkins 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 *pro
Hi Dmitry,
On Tue, Feb 10, 2015 at 1:43 PM, Dmitry Stogov wrote:
> On Feb 9, 2015 11:20 PM, "Yasuo Ohgaki" wrote:
> >
> > Hi Dmitry and Joe,
> >
> > On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov wrote:
> >>
> >> yes. this may work.
> >> probably better to put it after extends and implements.
>
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 be
On Feb 10, 2015 3:25 AM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> > 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 impleme
On Feb 9, 2015 11:20 PM, "Yasuo Ohgaki" wrote:
>
> Hi Dmitry and Joe,
>
> On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov 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
wrote:
>>>
>>> Co
On Tue, Feb 10, 2015 at 9:47 AM, Xinchen Hui 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.
--
Pi
Hey:
On Tue, Feb 10, 2015 at 3:19 AM, Jakub Zelenka wrote:
> On Mon, Feb 9, 2015 at 1:55 PM, Pierre Joye 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 an
On Feb 10, 2015 1:22 AM, "Lars Strojny" wrote:
>
> Hi Matteo,
>
> sorry for the late response.
>
> > On 07 Feb 2015, at 12:46, Matteo Beccati 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
sett
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
Hi Stas,
On Tue, Feb 10, 2015 at 9:24 AM, Stanislav Malyshev
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
Hi!
> 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
Hi all,
On Tue, Feb 10, 2015 at 5:27 AM, Yasuo Ohgaki wrote:
> On Tue, Feb 10, 2015 at 5:19 AM, Yasuo Ohgaki wrote:
>
>> Use of interface:
>> - no additional keyword (pros)
>> - requires interface for DbC, most classes does not require interface
>> (cons)
>> - if interface is not used, us
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
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 ..
Hi Lester,
On Tue, Feb 10, 2015 at 4:52 AM, Lester Caine 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
Hi all,
On Tue, Feb 10, 2015 at 5:19 AM, Yasuo Ohgaki 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)
>
Hi Dmitry and Joe,
On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov 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 wrote:
>
>> Could this be described as a requirement of the class ?
>>
>> class M
On Mon, Feb 9, 2015 at 7:22 PM, Nikita Popov wrote:
> On Mon, Feb 9, 2015 at 3:40 AM, Pierre Joye 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
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
Hi Bob,
The patch breaks few tests:
> Bug #64267 (CURLOPT_INFILE doesn't allow reset)
[ext/curl/tests/bug64267.phpt]
> Bug # #68937 (Segfault in curl_multi_exec) [ext/curl/tests/bug68937.phpt]
> ReflectionParameter::isDefaultValueConstant() &&
getDefaultValueConstantName()
[ext/reflection/tests/R
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 con
On Mon, Feb 9, 2015 at 3:40 AM, Pierre Joye 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
On 09 Feb 2015, at 16:04 , Sebastian Bergmann wrote:
>
> Am 09.02.2015 um 15:50 schrieb Pierre Joye:
>> Not strict? You loose me here.
>
> I want support for scalar types in signatures. I want these type
> declarations to be strictly enforced. This is not wanted and not
> proposed by the RFC. He
On Mon, Feb 9, 2015 at 1:55 PM, Pierre Joye 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 whe
>
> On 02 Feb 2015, at 17:35 , Derick Rethans 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 h
On Mon, Feb 9, 2015 at 1:22 PM, Lars Strojny wrote:
> Hi Matteo,
>
> sorry for the late response.
>
>> On 07 Feb 2015, at 12:46, Matteo Beccati 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
Hi,
> On 9 Feb 2015, at 18:22, Lars Strojny wrote:
>
>> On 07 Feb 2015, at 12:46, Matteo Beccati 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 de
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
S.A.N wrote on 09/02/2015 17:40:
2015-02-09 12:41 GMT+02:00 Rowan Collins :
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 p
Hi Matteo,
sorry for the late response.
> On 07 Feb 2015, at 12:46, Matteo Beccati 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
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
> i
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
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
On Mon, Feb 9, 2015 at 12:03 PM, Zeev Suraski 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,
Hi,
On Mon, Feb 9, 2015 at 7:22 PM, Jordi Boggiano 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 cal
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
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
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 wrote:
> 2015-02-09 12:41 GMT+02:00 Rowan Collins :
> > Yes, I can see it working well for specialised uses - you can simply not
> use those aspects of the language that don't ma
2015-02-09 12:41 GMT+02:00 Rowan Collins :
> 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 t
Hi Zeev,
> On 9 Feb 2015, at 17:03, Zeev Suraski 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*
> (al
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, th
On Feb 10, 2015 12:03 AM, "Zeev Suraski" 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
> >
>
> -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 wrote:
> >
> > A
On 2/8/15, 6:23 PM, "Stanislav Malyshev" 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 co
On 09/02/2015 15:50, Pierre Joye wrote:
On Feb 9, 2015 8:52 PM, "Sebastian Bergmann" 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
Dan Ackroyd in php.internals (Fri, 6 Feb 2015 16:16:09 +):
>On 5 February 2015 at 22:28, Rasmus Lerdorf 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 exten
Am 09.02.2015 um 15:50 schrieb Pierre Joye:
> Not strict? You loose me here.
I want support for scalar types in signatures. I want these type
declarations to be strictly enforced. This is not wanted and not
proposed by the RFC. Hence my vote.
--
PHP Internals - PHP Runtime Development Mailing
On Feb 9, 2015 8:52 PM, "Sebastian Bergmann" wrote:
>
> 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 co
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
On Feb 9, 2015 4:46 PM, "Jakub Zelenka" wrote:
>
> On Mon, Feb 9, 2015 at 9:18 AM, Anatol Belski
wrote:
>>
>> Hi,
>>
>> On Mon, February 9, 2015 07:33, Xinchen Hui wrote:
>> > Hey:
>> >
>> >
>> >
>> >
>> > On Mon, Feb 9, 2015 at 1:44 PM, Pierre Joye
wrote:
>> >
>> >> On Mon, Feb 9, 2015 at 11:10
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
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. sendin
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 on
On Mon, Feb 9, 2015 at 3:57 PM, François Laupretre
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
> >
> > invari
On Feb 9, 2015 6:07 PM, "François Laupretre" 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 fo
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
> meth
Hello internal,
Thank you Andrea for this RFC.
I voted today. However, I would like to stress that my vote represents
the opinion of Hoa's community [1] and fruux [2] (the company behind
sabre/dav [3]).
I talked to Pierre Joye today and I was mentioning this is something we
do since few mont
a...@ajf.me (Andrea Faulds) wrote:
> * Always allowing implicit conversions from int to float is sometimes
> going to cause data loss, so it may also be reasonable for PHP to
> prevent this specific case
IMHO, automatic conversion int --> float is perfectly reasonable because:
1) int can always b
Yeah, after
On Mon, Feb 9, 2015 at 11:27 AM, Dmitry Stogov 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 wrote:
>
>> Could this be described as a requirement of the class ?
>>
>> class Mine
> 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' ch
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 wrote:
> Could this be described as a requirement of the class ?
>
> class Mine
> require(invariant-expr)
> extends Something
> implements Someface {
>
>
Pierre Joye wrote on 09/02/2015 00:05:
On Mon, Feb 9, 2015 at 6:30 AM, Rowan Collins 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 definite
> On Feb 7, 2015, at 7:52 PM, Rasmus Lerdorf 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 ha
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 fil
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
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 co
> 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
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 wo
> 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 optimist
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 insid
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 impl
Hi,
> On 9 Feb 2015, at 03:48, Zeev Suraski 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
HI Dmitry,
On Mon, Feb 9, 2015 at 7:34 PM, Yasuo Ohgaki 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
On 9 February 2015 02:16:53 GMT, "S.A.N" wrote:
>2015-02-09 2:26 GMT+02:00 Rowan Collins :
>> 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 y
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 har
Hi Dmitry and Joe,
On Mon, Feb 9, 2015 at 6:01 PM, Dmitry Stogov 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.
Cur
Hi,
> On 9 Feb 2015, at 08:04, Dmitry Stogov 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, d
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 insidi
"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
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 consis
"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
On Mon, Feb 9, 2015 at 9:18 AM, Anatol Belski wrote:
> Hi,
>
> On Mon, February 9, 2015 07:33, Xinchen Hui wrote:
> > Hey:
> >
> >
> >
> >
> > On Mon, Feb 9, 2015 at 1:44 PM, Pierre Joye
> wrote:
> >
> >> On Mon, Feb 9, 2015 at 11:10 AM, Xinchen Hui wrote:
> >>
> >>> Hey:
> >>>
> >>>
> >>> On M
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.
Hi,
On Mon, February 9, 2015 07:33, Xinchen Hui wrote:
> Hey:
>
>
>
>
> On Mon, Feb 9, 2015 at 1:44 PM, Pierre Joye wrote:
>
>> On Mon, Feb 9, 2015 at 11:10 AM, Xinchen Hui wrote:
>>
>>> Hey:
>>>
>>>
>>> On Mon, Feb 9, 2015 at 10:40 AM, Pierre Joye
>>> wrote:
>>>
hi,
Should we pu
1 - 100 of 116 matches
Mail list logo
