(as in the last example given above). This is consistent
with the behaviour on deep-property access on scalars/null.
AllenJB
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
it
accepted.
Unfortunately the RFC window had basically closed at that time (and work
got busy shortly after), so now I've been waiting until 7.0 is clear (as
well as me having the time to finish drafting the RFC).
AllenJB
On , Sherif Ramadan wrote:
Hey Nicolai,
You're right. The notice
Wiki account: allenjb
I wish to submit an RFC for my notice on array-access on non-arrays pull
request.
Draft RFC: https://gist.github.com/AllenJB/793d54a86ac182ef61f5
PR: https://github.com/php/php-src/pull/1269
Thanks in advance,
AllenJB
--
PHP Internals - PHP Runtime Development Mailing
or take up the reigns on
this: https://github.com/websupport-sk/pecl-memcache/issues/4
At the very least if someone could add a header or obvious link to the
pecl.php.net page and manual pointing to the websupport-sk project, that
would help users in the mean time.
AllenJB
On 23/06/2018 15:16, Ja
Counter-view: I dislike enmod/dismod and think they're unnecessary
complexity. I like that, on almost every distro, as soon as an extension
is installed, it's enabled and I don't have to "jump through extra
hoops". I dislike tools like this that, as I see it, have no purpose
other than to
h sections, the "attempt" syntax would get very
messy (and risk introducing hard to see bugs) or require rewriting back
to a try/catch - in this regard I would say it's similar to ifs / loops
without curly braces and should be avoided.
AllenJB
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
issue) are not the recommended way, and may not act as users expect,
should they be deprecated?
Or at least notes added to the manual pages regarding this behavior /
the differences between the different methods?
AllenJB
--
PHP Internals - PHP Runtime Development Mailing List
uni (England), but as can be the case the
material was out of date and hadn't been revised in a few years. I have
no idea how to solve this problem because it stems from teachers who
don't care about the subject.
AllenJB
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
problems, such as accidental data
leakage, from cross-usage.
AllenJB
On 04/02/2020 13:03, Steven Wade wrote:
Hi all,
I’d like to officially open my __toArray() RFC <https://wiki.php.net/rfc/to-array> up
to discussion. I’ve delayed changing the status until I had more time to respon
?
If you want to change the way developers think about hashing when
writing PHP, I would start with the documentation rather than
deprecating functions which are essentially aliases and are highly
likely used all over the place in cases where they do exactly what
people want.
AllenJB
On 10/02/
This might be more a "future scope" thing, but I would like to see a way
to access the raw request body as part of this. Currently (as far as I
know) the only way is to open/read php://input, which isn't particularly
intuitive in my opinion.
AllenJB
On 10/02/2020 16:18, Paul M. J
would say this is a bad idea. I and a lot of other devs use
this functionality frequently (more often in POST, but often enough in
GET for purposes such as search pages). And how would multiple select
inputs be handled?
AllenJB
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
iews on making this change?
What do you think the new default be (and why)?
(I am aware this change will likely require an RFC)
AllenJB
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
issues, I intend to open voting
this weekend.
Regards,
AllenJB
On 28/03/2020 19:02, AllenJB wrote:
Hi,
I present for discussion an RFC to change the default PDO error mode:
https://wiki.php.net/rfc/pdo_default_errmode
Previous discussion: https://externals.io/message/109015
I believe t
/109015
* https://externals.io/message/109398
Voting closes on April 27th.
Regards,
AllenJB
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
case when anything
but silent is a good default (with exceptions just being a better
default for modern PHP in my opinion).
Regards,
AllenJB
On 14/04/2020 07:52, Christian Schneider wrote:
Am 14.04.2020 um 03:10 schrieb Derick Rethans :
On Mon, 13 Apr 2020, Christian Schneider wrote:
Am 13.04.
Hi,
Please could I have rfc karma on the wiki account 'allenjb' to bring
forward my RFC for changing the default PDO error mode (
https://externals.io/message/109015 )
Thanks in advance,
AllenJB
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
be confusing, when using
PDO unless they implement "boilerplate" error handling every time a
query is made.
I believe it also brings the behavior inline with what developers would
actually expect the default to be in modern PHP.
Regards,
AllenJB
--
PHP Internals - PHP Runtime D
), that'd be great. (Specifically tests need updating where they
don't explicitly set the PDO error mode). I've already done pdo_sqlite
and pdo_mysql and pdo_dblib has been checked.
Thank you all,
AllenJB
On 13/04/2020 13:41, AllenJB wrote:
Hi all,
I have opened voting on the RFC to change
the lower length and can take the tradeoffs).
AllenJB
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 13/04/2020 13:41, AllenJB wrote:
Hi all,
I have opened voting on the RFC to change the default PDO error mode:
https://wiki.php.net/rfc/pdo_default_errmode
As no concerns were raised during the discussion period, the RFC is
unchanged from that originally posted.
Previous discussion
they're going to be
asking about this deprecation message (or worse, changing
error_reporting or using @ to silence it!). Without a deprecation phase,
existing examples will continue to work (errors will just be reported
differently, but no in an unintuitive way in my opinion)
AllenJB
--
PHP
fic link anchors
that already exist in the manual but are not obvious unless you use a
browser plugin that exposes them).
(It also appears to be missing information on array destructuring and
unpacking features from 7.3 and 7.4 - an example of the specific manual
sections not being updated that
ot enabled by default?
Are there any other session (security) related settings that should be
tightened by default? (cookie_samesite?)
AllenJB
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
cter count, token length / end character count
A case where I can see this still not helping is cases where the parse
error can occur several lines after the actual error (or even at the end
of the file) due to things like missing quotes / braces.
AllenJB
--
PHP Internals - PHP Runtime D
here)
You may also want to check threads / the RFC related to named parameters
as there may be additional discussion there.
AllenJB
On 14/01/2021 17:52, Andrew Brown wrote:
This is my first foray into PHP internals, so please let me know if
I'm doing something wrong. Currently just
-sensitive representation for integers (and
decimals) here?) (and now we're getting into "why are we still using
floating point math by default in 2021" territory, so I'll stop right here)
AllenJB
PS. Apologies for the dupe to those who did receive my original send,
but I forgot to a
On 04/03/2021 14:08, G. P. B. wrote:
Hello internals,
This new RFC which I'm proposing is to extend the capability of the error
control operator @ to not just suppress diagnostic messages but also
exceptions.
It can currently be found on GitHub: [1]
On 28/02/2021 12:49, Eugene Sidelnyk wrote:
Hi there!
I faced a lack of methods overloading in PHP once again and would like to
ask will it be implemented at some point?
As well, I want you to show some pros and cons which you see in this
feature.
Here're some thoughts about this by Yegor
On 14/08/2021 00:27, Jordan LeDoux wrote:
Hey internals,
I've been working on the draft for my operator overloading RFC, and in
doing so I encountered a separate change that I would like to see.
That is, the use of `never` as an argument type for interfaces. Since
arguments in PHP are
On 01/01/2022 23:17, Craig Francis wrote:
I've spent a few days coming up with a short(ish) list of parameters that
are likely to receive `NULL`.
The focus is on making it easier for developers to upgrade to newer
versions of PHP. I'm thinking of the typical developer, probably using
WordPress,
On 18/07/2021 10:08, Abdul Haq Sheikh wrote:
Hello Internals,
PHP has built in functions for string, array and math etc. But some string
and array functions start with Str_* and array_* but not all. If we
standardize php builtin functions so all string functions start with str_*,
and all
On 18/07/2021 03:41, Jordan LeDoux wrote:
Related to the general topic of injection attacks, I was considering
submitting a PR to change the default of PDO::ATTR_EMULUATE_PREPARES to
FALSE, since this mistakenly can lead people to believe that using prepared
statements with PDO and MySQL
On 16/07/2021 09:11, Eugene Sidelnyk wrote:
Thanks for your response!
Anyway, I probably put it wrong by saying "by default", so let me clarify
myself.
What I really mean is omitting the dollar sign. So everything remains the
same with ordinary properties (which are mutable), and we introduce
34 matches
Mail list logo
