Hi!
> Points explicitely marked for discussion in the RFC itself:
>
> * pecl/propro
> Proxies for properties representing state in internal C structs
> https://wiki.php.net/rfc/pecl_http#peclpropro
>
> * pecl/raphf
> (Persistent) handle management within objects instead of resources
> ht
Hi!
> We are talking about adding support for scalars (string, integer, ...)
> to the list of optional type declarations already supported (array,
> callable, interface name, class name) by PHP. When a developer chooses
> to use a scalar type in the signature of a function or method then it
>
Hi!
> Adding another concept, not changing the existing ones. And really,
> it's just simplifying what is already present via is_()
> runtime checks, making our lives a little bit easier.
There's a very big difference between allowing to check types (and then
do whatever you wish) and having func
Hi!
> True, but obviously, us who want strict typehints want to be able to do this:
Obviously, but it doesn't mean whole language should be changed to serve
one use case, especially the one that goes contrary to what happened in
PHP for decades.
--
Stas Malyshev
[email protected]
--
PHP Inte
Hi!
> think raphf is far more of practical use. Why should HTTP, or even more
> HTTPS or HTTP2, be any different than another service, especially when
Which "another service"?
> HTTP APIs are so common nowadays.
HTTP APIs are common, but almost none of them ever require persistent
connections.
Hi!
> Databases (see my pecl/pq example in the RFC), key/value stores, message
> queues, whatever you can think of.
HTTP and databases are principally different. HTTP protocol is stateless
message-oriented protocol, and database connection protocols have very
little in common with HTTP.
> To dem
Hi!
> However I feel like the fact that it only affects your app (even if
> you use a library relying on strictness) if you want to is not clear
> for everyone replying here. Is this point clear for you?
I was addressing the idea that every scalar type mention should be
strict. If it is a choice,
Hi!
> Yes, I mean $_POST (and $_FILES). It's been requested multiple times,
> but I know it's quite controversial. I think this approach is better
> than any other proposed yet (think $_PUT and stuff).
You're building an OO next-generation API, why you still need $_PUT or
$_FILES or anything like
Hi!
>> I can try to make a patch to solve it, but before that I would like how
>> the behavior should be. Some options:
>> 1) Give the notice saying the field doesn't exist and do not include on
>> the serialized response
>> 2) Give the notice saying the field doesn't exist and convert the value t
Hi!
> If we allow larger type, why doesn't such code work ?
>
> interface A { }
> interface B extends A { }
>
> class C {
> public function foo(A $a) { }
> }
>
> class D extends C {
> public function foo(B $a) { } // E_STRICT
> }
>
> This is wrong IMO.
This shouldn't work - it means t
Hi!
> Does the following kcachegrind screenshot give an idea (I used a minimum
> node cost of 10% to simplify the graph)?
>
> Left is raphf enabled (24M Ir) and on the right raphf disabled (35M Ir):
> http://dev.iworks.at/ext-http/raphf.png
>
> Have a look on the top-most far-right highlighted b
Hi Anatol!
Your recent fixes to headers_list() -
55cefb2814bde5815a92e8820fff45e037fa8d4f and
b5d3c5ca8dee6303498849448e3574cc3642eeea - broke head.phpt test and also
are BC-breaking since previously headers_list() always returned an array
(empty one if there are no headers), now it returns false
Hi!
> Uhm, I'm not sure I understand :-? Weren't I supposed to measure exacly
> that? Let me know, if you wanted something else to be compared.
I wanted to know why we need persistent resources. You brought comparing
persistent resources to reopening connection each time as an argument
that we ne
Hi!
> I don’t think it’s unfair. There’s a limited set of permitted
> conversions in some strictly-typed languages, but it’s still
> strictly-typed.
The main problem with strict typing as it is being proposed by
strictness proponents is exactly that - there's no limited set
permitted. It leads to
Hi!
> * Requiring an exact type match has the least mental overhead, and
> allows types to be checked at compile-time
What compile-time you're talking about? PHP has no "compile time".
--
Stas Malyshev
[email protected]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Hi!
I'd like to announce a vote on parameter skipping RFC:
https://wiki.php.net/rfc/skipparams
TLDR: it allows using "default" to specify that parameter has the
default value when calling function with optional parameter, like this:
create_query("deleted=0", "name", default, /*report_errors*/ tru
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 conn
Hi!
>> Last, voters should take into account that this isn't an 'either this RFC or
>> nothing' situation. I think it's very unfortunate that the original RFC -
>> that had zero controversy surrounding it - was never put to a vote.
>
> Please stop repeating this, it is blatantly false and I’ve p
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
Hi!
> On 2/8/15, 11:38 AM, "Derick Rethans" wrote:
>>
>> Btw, I only voted no because I don't think we should just remove it. A
>> reimplementation of its APIs on top of eg. Open SSL makes sense. And that
>> I'd vote yes for.
>
> This idea makes me nervous. It doesn't sound at all easy and will
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, otherwise building from release package without re2c
would be impossible, and I think before it was possible. In any case, we
should be consistent - if we commit genera
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!
> Please steer clear of using the assert API, and in so doing avoid BC
> concerns with the current assert API.
The operator can be called something other than "assert", I'm sure the
thesaurus has a lot of possibilities.
> Please avoid adding a magic method and use the suggested syntax for
>
Hi!
> Hello, internals!
>
> DbC is good thing, but the way you want to do this via language changes is
> really awful. Why do you want to add more custom features into the
Agreed here. I still don't see what's wrong with just putting the code
at the beginning of the function and whenever you wan
Hi!
> I proposed script()/script_once() at first. Considering new names that
> might
> break existing apps, I choose INI.
The problem with script_once is not that it may break existing apps. The
problem is that somebody careful enough to use special operator would
probably be careful enough not t
Hi!
> 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.
I think there are several issues with this RFC:
1. It does not prote
Hi!
> 1) contracts in doc-commetns https://wiki.php.net/rfc/dbc
>
> /**
> * @requires ($a >= 0)
> */
> function foo($a) {
> }
We've spent several years rejecting annotations because no information
can be in comments, not even a little bit, not even a tiny. Now we'd
have full-blown running code
Hi!
>> function foo($a)
>> require($a >= 0)
>> {
>> }
>
> This is a step better but still we have the similar issues with
> readability, to which reuse of 'require' is added.
Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.
OTOH, don't our new parsing i
Hi!
> I'm not trying to be perfect, but I would like to make PHP as secure as
> other
> languages from script inclusion attacks. It's too easy currently...
PHP is already as secure as the other languages. If you have code in
Python that loads arbitrary file and executes it, you could upload
Pytho
Hi!
> That one actually looks better to me, but: I'm not sure how annotation
> syntax is supposed to support expressions or closures,
>
>
> keep AST.
So we'd have a zval type that is the raw AST? Would it also be available
to user functions or internal functions/classes? It's an intrigu
Hi!
> class A {
> // This is an *instance* method, but it doesn't actually use $this.
> // This kind of usage is very common in PHP 4 era code, where
> // "static" annotations weren't used
> function test() {
> echo "foo";
> }
> }
>
> class B {
> function test2() {
Hi!
> And yes, I'm pretty sure there is intent to remove this completely in the
> future - this is just another leftover from PHP 4. The approach outlined
> here only avoids dropping support in PHP 7 already (which the original
> patch did for all practical purposes).
Why btw remove it? OK, someb
Hi!
> It was always an E_STRICT error to call a non-static method statically
> (as usual, not counting scoped calls) and since PHP 5.6 it was
> E_DEPRECATED in the most common case. I don't see why we would suddenly
> want to go back on this and make it work without any warnings.
The reason why i
Hi!
> Such code will break, not in the first place but later on!
Later on when?
> You propose that every instance method not using the variable $this
> internally will be magically a static method and can never ever be
The difference between static method and non-static method is pretty
much th
Hi!
> there should be no bc break as the API doesn't change and the method
> produces the exact same result as before.
Sorry, this makes no sense to me. You claim that if you changed the
method code to do different thing it should continue working as if you
didn't change it? Why? I just don't get
Hi!
> My proposal is to deprecate the use of var on properties in PHP 7, and then
> remove support for it in PHP 8. This compliments the [0] "Remove PHP 4
How the life of the PHP user would be improved by this? Except for
making more code break, I'm not sure how it's helpful, could you explain?
Hi!
>> > there should be no bc break as the API doesn't change and the method
>> > produces the exact same result as before.
>>
>> Sorry, this makes no sense to me. You claim that if you changed the
>> method code to do different thing it should continue working as if you
>> didn't change it? Why?
Hi!
> I’ve written a small RFC and patch to add a “void” return type:
>
> https://wiki.php.net/rfc/void_return_type
>
> Please have a read over it. I think this would be a simple, yet useful
> addition.
I'm not sure what it is useful for, exactly. I mean, the more fatal
errors the merrier, but
Hi!
> What would be the point of *allowing* returning a value? It's clearly
It's an error only because you declared it an error.
> an error. We could let you return anything and then discard it, but
> now you won't spot the error in your code.
Function return values which are going unused all t
Hi!
> One of the primary purposes of having typehints *is* documentation. This
Documentation causing fatal errors is something quite unusual. And wrong.
> applies both to our existing type annotations, to the newly introduced
That is not true, for existing types documentation is not the only an
Hi!
> How ignoring values is a perfectly valid scenario?
You are saying you're using return value for every function you're
calling, always? Please. How many times you used return value of sort()?
Every function with side effects can be used for its side effects, not
for its return value.
> new
Hi!
> Agreed. Personally, I'm a great fan of symettry, so part of me would
> prefer to introduce a keyword for when you *can't* call a method
> statically, e.g. "instance function foo() { ... }". But I guess instance
This would be another form of saying "foo() method uses $this", but if
that's tr
Hi!
Since Andrea has withdrawn the spaceship operator RFC
(https://wiki.php.net/rfc/combined-comparison-operator), I'd like to
resurrect it. Looks like by vote results (with 1 day of official vote
left) it was clearly passing, so are there any objections to treating it
as passed? If not, I'll trea
Hi!
> Are you sure that "the ini file is created by the package maintainer and
> it includes the “date.timezone” setting" is true? Last time I checked it
I my experience, it is unfortunately not universally true - I've seen
Linux distros with ini files that don't do that. Setting TZ correctly
wou
Hi!
> About your question, I don't know... treating a cancelled voting result
> as if it wasn't might be setting a weird precedent, even though it was
> so close to the end and had an overwhelming majority.
The only reason it was cancelled because of Andrea quitting, and with
one day left result
Hi!
> Reopen it for one day. It's quite crazy but it does not create a
> precedent. Andrea said she gave the RFC to anyone wishing to go on
> with it. If you officially take over the RFC, you are the owner, you
> can do that.
OK, I've put it back to vote for a day. Will close it tomorrow.
--
St
Hi!
> One thing of note is that I didn’t write a language specification
> patch. If you’re to pick it up, I guess you’d have to do that at some
> point, sorry about that.
No problem, I'll take care of it, thanks for the reminder.
--
Stas Malyshev
[email protected]
--
PHP Internals - PHP Run
Hi!
> The test there is self explainable. Of course, annotations just provide
> a way to add metadata, but doesn't define attribute names or the ways
> they are going to be used. Only Reflection API to read.
Looks fine, but I'm not sure how one can use the AST that the reflection
returns. Is it f
Hi!
As expected, spaceship operator RFC
(https://wiki.php.net/rfc/combined-comparison-operator) passed 43 votes
to 11. I'll proceed with merging it soon.
--
Stas Malyshev
[email protected]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
Hi!
> So let's talk compromise.
> Would leaving internal functions out of the picture at this stage
> change you mind? This is effectively what Hack does, internal
> functions are explicitly marked as "coercible".
For me, the option that makes users remember which functions are
internal and whic
Hi!
> 2) PHP would benefit hugely from static analysis tools and compile-time
> type-based optimizations, but those are only possible with code that is
> strongly typed. Currently such tools do not really exist, but with
Is that really the case? Javascript has very good optimizing engine, and
Ja
Hi!
> So rather than go for the 70-75% consensus that we **know** we have,
How we magically know that? We have the (unfinished) vote, which has a
tiny bit over 66% for the proposal. Where 75% comes from?
> Saying a problem doesn't exist doesn't make it go away.
Except if it really doesn't exist
please visit our
downloads page: http://www.php.net/downloads.php
Windows binaries can be found on http://windows.php.net/download/
The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.4.38
Stanislav Malyshev
PHP 5.4 RM
--
PHP Internals - PHP Runtime Development
Hi!
> Based on the no reasons that people presented, and some back-of-envelope math.
That is not "knowing", much less "**knowing**". That is a guess based on
an estimate and set of assumptions, some of which very well may be wrong
(such as, people can have more than one reason to vote no).
> The
Hi!
> At the function border, yes. But not beyond that.
Not sure what you mean here. If the value is identified as int, it
remains int. How strict typing would change that?
> Sort-of correct. We don't know if A is true, but we know what
> conditions need to exist for A->B to be true. We know tha
Hi!
> cc'ing Stas as he was the author for this change.
> but from my understanding this isn't a problem as we disallow setting
> multiple headers in a single header() call for years (even though we had
> a regression at one point).
Well, we allowed multiline headers but it is an extremely exotic
Hi!
> A JIT or AOT machine code generator IMHO will never have a decent use of
> system resources without some sort of strong/strict typed rules,
> somebody explain if thats not the case.
Yes, that's not the case, at least nobody ever showed that to be the
case. In general, as JS example (among m
Hi!
> I think this will be the final discussion before vote.
> This RFC is to make PHP stronger against script inclusion attacks just like
> other languages.
>
> https://wiki.php.net/rfc/script_only_include
I still think this RFC takes a wrong road for the following reasons:
1. Having any code
Hi!
> RFC: https://wiki.php.net/rfc/context_sensitive_lexer
> TL;DR commit: https://github.com/marcioAlmada/php-src/commit/c01014f9
> PR: https://github.com/php/php-src/pull/1054
I like the idea. But we need to examine the cases carefully so we don't
block some future routes - especially this is
Hi!
> I see a LOT of "no" votes against this RFC but can't find the thread
> outlining the reasoning for such resistence.
I think my attempts to explain that this was a step towards named
params, not a contradiction with them, failed - people read it, say "we
understood it" and the say "no, we do
Hi!
> Well, strict on a JIT environment may haven't been proved, but it surely
> has been proved on statically compiled languages like C. Currently, a
I understand that using the same concept of typing in both cases can be
confusing, but that's pretty much where the similarity ends. Strict
typing
Hi!
>> -- Can the code generated for a strict type hint can somehow be optimized
significantly better than the code generated for a dynamic/coercive type
hint.
> And me, who wrote an AOT compiler that does **exactly** this, claim
Sorry, did exactly what? Here a bit more explanation would help.
>
Hi!
> I do not see much gain today to "improve" them while I do not see why we
> should not. It does not hurt.
The gain is simple - today, assertions have costs so people that are
performance-conscious (rightly or wrongly) use them less than they
could. We can make them cost-less in production, w
Hi!
> You can tell because you know the function foo expects an integer. So
> you can infer that $x will have to have the type integer due to the
> future requirement. Which means the expression "$something / 2" must
> also be an integer. We know that's not the case, so we can raise an
> error her
Hi!
> It is still a performance advantage, because since we know the types
> are stable at compile time, we can generate far more optimized code
> (no variant types, native function calls, etc).
I don't see where it comes from. So far you said that your compiler
would reject some code. That doesn
Hi!
> The difference though is the journey. The static analyzer can reason
> about far more code with strict types than it can without (due to the
> limited number of possibilities presented at each call). So this
> leaves the dilema: compiled code that behaves slightly differently
> (what Recki d
Hi!
> This makes it impossible to use this feature with some of the ext/std
> functions (array_udiff, array_interect_ukey, etc.) and just feels a bit
> incomplete...
I see how it can be useful with crazy functions like array_udiff, but
these are in tiny minority. What I am concerned about is that
Hi!
> It rejects code because doing code generation on the dynamic case is
> significantly harder and more resource intensive. Could that be built
> in? Sure. But it's a very significant difference from generating the
> static code.
I can appreciate that. Dynamic typing is hard to translate into
Hi!
> How is coercive much smarter? Basically what coercive would do is
It can accept 2.0 but not 2.5. Explicit cast is a sledgehammer - it
would convert both to 2.
> How casting (int) could be such dangerous thing? Lets take for example
> this code:
>
> echo (int) "whats cooking!";
> echo int
Hi!
> I noticed very strange behavior under ZTS build with this patch.
> It turned out that compiler_globals is not accessible under ZTS build
> according to gdb.
>
> Is this intended? If so, where should I put script_extensions char array?
That doesn't look right. If compiler_globals weren't ac
Hi!
>
> I would like to propose reclassifying our few existing E_STRICT notices and
> removing this error category:
>
> https://wiki.php.net/rfc/reclassify_e_strict
Could you add some more explanation about why it is a good thing? I.e.,
E_STRICT has pretty clear place and hurts no one, why
Hi!
> The same applies to private mails about open topics, rfc or patch to try to
> get one to change her mind. This is not acceptable and will never be, to my
> eyes at least.
I think it's completely OK to discuss whatever matters people like to
discuss anywhere, as long as this does not hurt th
Hi!
> So because of the described issues with the existing code base I like to
> propose the change to no longer ignore undefined arguments and introduce
> E_DEPRECATED messages if a function get's an undefined argument. So the
> user get enough time to fix their code before throwing errors in thi
Hi!
> https://wiki.php.net/rfc/anonymous_classes
>
> There's a little RFC + patch that Joe Watkins put together, and as
> before with the ArrayOf RFC, I'll be helping out.
>
> So, lets get this discussion rolling.
This is a nice and clear proposal, however I'm not sure I'm completely
convinced
Hi!
> I like the idea of having anonymous classes, it is very helpful during
> development to just try something out without having the burden of
> creating a new file and a complete class including namespace and use
> declarations, etc.
I think this particular argument is a bit backwards. In PHP
Hi!
> Will it add a significant level of protection? No.
>
> Does it add protection? Yes.
>
> Each time we add some incremental security hardening, we make it a bit
> harder to create vulnerabilities. In this case, if there were code
In this case, it seems not to be much harder than changing an
Hi!
> I've made PR proposing a feature request: A new interface Sortable.
>
> https://github.com/php/php-src/pull/1116
>
> If possible, I would like to create and RFC describing this in more detail,
> and perhaps get a voting on.
Can't you sort any class that provides ordered list of elements a
Hi!
> They'd need to upload with a matching file type. Instead of any file
Not sure what you mean by that. phar can read tars, etc. AFAIK, can't
it? Also, phar archive has no requirement of being named something.phar,
afaik can be also named cuteponies.gif. E.g., I just did this:
1. Created file
Hi!
> I would like to add a note for this.
> Anti Virus products are detecting this type of files as "PHP malware".
It looks like you are trying to convince me that PHP malware exists. I
would like to save you time by notifying you I am aware of this. My
disagreement is not denying PHP malware ex
Hi!
> I think he means matching file "extension". File extension should
> represent file type, though.
You can not rely on that. I can name files anything regardless of what's
in the file.
> Since "pwnd.php" has ".php" extension, move_uploaded_file() refuses to
> move it
> to upload dir by defau
Hi!
> require('cuteponies.gif) wouldn't work with this RFC.
> move_uploaded_files() prohibits uploading PHP script.
You seem not to be reading the scenario. The include URL would be
phar://cuteponies.gif/pwnd.php and the uploaded file would be
cuteponies.gif. Your protection would not stop movin
Hi!
> As far as I know, PHP is the only language that has this type of malware.
> (Script embedded images) PHP is the only one malware vendors claims
> it as "PHP malware". This is the fact.
Which type is that? Of course only malware in PHP can be presented as
"PHP malware", but I don't understa
Hi!
> Your example omitted the image validation step which would have
Ah, right, and if I name it .zip, it'd be zip validation, and if I name
it .pdf it'd be pdf validation, and if I name it .lol that would be LOL
validation. You'd have to manually validate every type in existence and
somehow inv
Hi!
> That was indeed my point as Yasuo has already explained earlier. Image
> validation would however see a phar a mile off.
How much would you bet against the possibility of a file existing that
can both pass as an image file of some type and as a valid zip or tgz or
tar file? Hint: don't go t
Hi!
> - require/include only includes ".php" ".phar" by default.
This is not true. As I repeatedly point out, your change only requires
that the string passed to include would end in .php, but string passed
to include and filename on filesystem are very different things, they do
not have to be t
Hi!
> Are you saying current PHP allows
> include('zip://...') or include('input://...')?
Neither zip not phar are classified as url handlers. Both have is_url to 0.
> Then this is serious bug. I'll fix it also.
This would be another big BC break, as this would mean you can not use
phar streams
Hi!
> I have to at least php://
> php://input or php://stdin
> allows attacker script execution via POST if it's allowed
> by allow_url_include=On.
allow_url_include=On means it's allowed. That's what "on" setting is
for. Production setting should always be "off".
--
Stas Malyshev
smalys...@gm
Hi!
> For example, the number of users that actually need to do something
> better than read from /dev/urandom is small. A user that is concerned
Good summary read on the topic: http://www.2uo.de/myths-about-urandom/
TLDR: it's ok to use /dev/urandom.
--
Stas Malyshev
[email protected]
--
P
Hi!
> I saw you voted "no".
> Could you share us the reason behind?
I think I did, in my past messages to the list, but maybe I was not
clear. I will repeat in short:
1. I think this RFC does not provide any security improvement, due to
extreme ease with which the measures in this RFC can be cir
Hi!
> This is only a minor detail, compared with the other PHP7 changes.
Not that minor actually since you'd have to enumerate all extensions
used in your app, which can use libraries, which may use other
extensions - like Smarty or some other template library - and it may be
non-trivial to find
Hi!
Padraic, I'm not really interested in another prolonged discussion,
especially where my arguments are ignored or misconstrued and then
dismissed. I have explained my opinion, if somebody has questions about
the substance of my arguments or need me to clarify my points, rather
than flat-out den
Hi!
> I'm cool with that idea but I also think it should be spelled out like `
> random_crypto_*()` as Pierre suggests. I like `secure_random_bytes()` but
> that's because it's what Ruby names their CSPRNG. :)
The custom is that the first word names the function group (yes, I know
old functions d
Hi!
> This can be prevented by restricting phar archive name or forbid all
> URI name at all. The latter is better choice.
If by "all uri" you mean all streams, that would be very high burden,
which may break many applications using streams, including phar handling.
> There is design problem obv
Hi!
> SInce allow_url_include change is very simple one, I've just made new RFC
> for it.
>
> https://wiki.php.net/rfc/allow_url_include
>
> If you find any other issue like this that relates to this RFC, please
> let me know
> I'll put this discussion shortly.
I'm not sure what this RFC is try
Hi!
> For this concern, we have 2 classes of wrappers "local" and "remote".
> php://input and php://stdin would be issue, since it contains "remote"
> input under Web SAPI while it is "local" with CLI. We may handle
> php://input and php://stdin separately.
php streams are marked with is_url = 0
Hi!
> I have no intention to change current include/require syntax, except adding
> 2nd parameter.
This is a bit misleading since include is not a function, so there's no
1st parameter. Instead, it's a syntax construct. Of course, syntax
construct's grammar can be changed, though I'm not sure if
Hi!
> The root cause of the issue here is preciseness of the setting.
> I think you agree that current "allow_url_include=Off" with INI_SYSTEM is
> not precise at all.
It is precise - it's doing exactly what it meant to do, separate local
wrappers from remote ones.
> We need to consider local a
Hi!
> Hi all,
>
> https://wiki.php.net/rfc/introduce_design_by_contract
>
> This is vote only RFC for 2 competing Design by Contract(DbC) RFCs.
> Please comment if you have any for this RFC.
I don't see why the first one needs any vote. It is supposed to be
implemented as an extension, so why n
Hi!
> This email is to announce the formal opening of discussion for an RFC
> to clean up the behaviour of the constructors shown by several
> internal classes.
>
> https://wiki.php.net/rfc/internal_constructor_behaviour
I'm not sure why this RFC assumes the exception is much better than
returni
Hi!
> This proposal is about code modularization. Software engineering is
> a history of better modularization.
>
> - Structured programming
> - Object Oriented programming
> - AOP
> - DbC
>
> Exception is one of them.
I'm sorry, I have hard time understanding what exceptions have to do
wi
1 - 100 of 3265 matches
Mail list logo
