Re: [PHP-DEV] Re: Alias for `int|float`

[Ryan Jentzsch]

`number` type But frankly this seems a bit silly and reminds me too much of
JavaScript.

On Wed, Sep 28, 2022, 9:08 PM Hamza Ahmad 
wrote:

> Hi Olle,
>
> I appreciate your idea of introducing a similar concept of typedef.
> What if you write an RFC explaining that concept. I can join you
> however in co-authoring this request.
>
> Seriously, I have had issues with writing such type again and again.
> If you look at mixed type, it is indeed an alias of some union types.
> Adding such an option to userland would lead to introduction of
> various type hints. Plus, it will help devs write short hand aliases
> for their intersection types.
>
> Regards
>
> Ahmad
>
>
> On 9/27/22, Olle Härstedt  wrote:
> >>Hello, internals!
> >>
> >>What do you think about creating shorthand `number` for `int|float`?
> >
> > This is also related to allow all types of type-hints in the
> use-statement,
> > like
> >
> > use int|float as numeric;
> >
> > Anyone interested in creating an RFC for this?
> >
> > Olle
> >
> > PS. Original thread here: https://externals.io/message/112209#112209
> > (dunno how to respond to an old thread when I don't have the original
> > message)
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces

[Ryan Jentzsch]

Answering the question: How do other languages handle this problem? Or how
do they avoid it in
the first place?

Python basically doesn't handle the problem at all and offers this advice: Be
sure to delete all debugging related code before code delivery!

See section [9.2.1 production code cannot contain any debug entry points]

https://www.fatalerrors.org/a/python-general-programming-specification-09-security-programming-specification.html

On Mon, Jan 10, 2022 at 10:01 AM Dan Ackroyd  wrote:

> Hi Tim,
>
> On Mon, 10 Jan 2022 at 14:05, Tim Düsterhus, WoltLab GmbH
>  wrote:
> >
> > this is a follow-up for my "Pre-RFC" email from last Friday, January,
> 7th.
> >
> > https://wiki.php.net/rfc/redact_parameters_in_back_traces
> >
>
> How do other languages handle this problem? Or how do they avoid it in
> the first place?
>
> From the RFC:
> > Specifically the back trace collection should be updated to use an
> object of class
> > \SensitiveParameter as the value for all parameters that are marked with
> the
> > \SensitiveParameter attribute.
>
> To methese words are not clear. Does the following sentence say
> the same thing?
>
> "When the backtrace is generated, any parameter that has a
> 'SensitiveParameter' attribute will not have it's value stored in the
> backtrace, but instead will be replaced with an SensitiveParameter
> object.
>
> If so, the RFC could be updated to be clearer.if not, then the RFC
> should be updated to be clearer.
>
> Also, having parameters replaced with another type doesn't seem
> obviously correct. There should probably be some words justifying why
> that is the correct thing to do, rather than just replacing any values
> with "REDACTED***" or other simple behaviour.
>
> > On shared web hosting, the customer might not be able to configure it.
>
> My personal opinion is that shared web hosting shouldn't be a thing
> that exists in 2022. And definitely shouldn't be used for anything
> where secrets need to be maintained. Yeah shared hosts might have a DB
> they can connect to, but those credentials should only be usuable from
> the shared host to the DB.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Add PDO function: mysqlGetWarningCount

[Ryan Jentzsch]

Is there a process in place for RFCs that address bugs in bugs.php.net if
they have a passing vote to mark the bug as "FIXED in version xx.xx.xx" or
if the RFC doesn't pass mark the bug as "WONTFIX"?

On Mon, Jul 26, 2021 at 6:49 AM Peter Cowburn 
wrote:

> >
> > On Jul 6, 2021, at 08:34, Daniel Beardsley  wrote:
>
>
>
> Voting will be open till 2020-07-21
> >
>
> This date has passed, yet the vote is still ongoing.
> Daniel, could you please close the vote and do the usual follow up tasks?
> If Daniel is unavailable, what is the process for *someone else* doing
> those things?
>

[PHP-DEV] T_PAAMAYIM_NEKUDOTAYIM is terrible, are we sure we're OK with it?

[Ryan Jentzsch]

https://phil.tech/2013/wtf-is-t-paamayim-nekudotayim/

Re: [PHP-DEV] Making the hardcoded string length limit of Throwable->getTraceAsString() configurable

[Ryan Jentzsch]

Why is there a 15 byte limit in the first place?

On Wed, Jun 24, 2020, 1:22 PM tyson andre  wrote:

>
> Hi internals,
>
> By default, strings in parameter lists are truncated to 15 bytes by
> default in Throwable->getTraceAsString()
> (and Throwable->__toString() as a consequence).
> (in Zend/zend_exception.c in `static void _build_trace_args(zval *arg,
> smart_str *str)`)
>
> This limit is too short to see relevant information such as file paths,
> full urls, etc, which makes reporting bugs in applications inconvenient.
>
> Would there be any interest in an ini setting such as
> `exception_string_length_limit` as a non-negative value to raise this
> (either allowed to be 0 or more or 15 or more, defaulting to 15)
>
> It's possible to manually work around it by calling Throwable->getTrace(),
> but inconvenient,
> and there's always a concern about the user-space trace generation having
> its own issues
> (e.g.
> https://github.com/phan/phan/blob/3.0.3/src/Phan/Debug/Frame.php#L25-L132)
>
> In applications that don't have a custom exception handler, users could
> raise this to make creating bug reports easier.
>
> ```
> php > test('12345678901234567890');
> Warning: Uncaught Exception in php shell code:1
> Stack trace:
> #0 php shell code(1): test('123456789012345...')
> #1 {main}
>   thrown in php shell code on line 1
> ```
>
> Thanks,
> - Tyson
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Ryan Jentzsch]

OMG the trolling continues even today with this nonsense. Disappointing.
Calling T_PAAMAYIM_NEKUDOTAYIM a non-issue is simply wrong and here's why::
"People don’t ask for the other parse errors even half as often as they as
for T_PAAMAYIM_NEKUDOTAYIM They do so because it looks like gibberish to
them, so it looks unlikely to be a common thing you can Google, nor it
gives something recognizable to start with [sic] Yes, we all acknowledge
it’s an easter egg joke that refers to the creators of PHP. But that
particular joke has outworn its welcome in the community after repeatedly
CAUSING SUPPORT ISSUES." -Stan Vass (emphasis mine)

"It's a minor change and an annoyance to a lot of people. Yes, by not
changing this you’re annoying thousands of people." -Alexander Schrijver

"It’s the same argument everyone else is giving, and really it all comes
down to this.:
Nostalgia is valued over clarity and consistency. Do you guys REALLY want
to claim that?" -Chad Minick

"...yes, it is broken, people have to Google or ask around for a very
unclear error message when for the most part errors are (and should be)
self explanatory
...Two things are broken: Either the token is named badly, or the token
names shouldn’t show up in error messages at all and be replaced with
something a bit more friendly.
...What is so hard to believe when people see UNEXPECTED T_DOUBLE_COLON on
LINE 23 they are gonna look for a double colon on line 23?" -Chad Minick

Once again I plead for logic and sanity. At least have the courage to put
it to a vote.

On Wed, Jun 10, 2020, 12:28 PM Claude Pache  wrote:

> Hi,
>
> I appreciate the effort to reduce frustration in PHP coding.
>
> However, T_PAAMAYIM_NEKUDOTAYIM is a non-issue: you learn it once and
> you’re done for the rest of your life.
>
> May I suggest an improvement that would be much more useful than renaming
> tokens?
>
> One parsing error that I still find dreadful after more than 10 years of
> PHP coding, is:  unexpected T_CONSTANT_ENCAPSED_STRING. Although
> T_CONSTANT_ENCAPSED_STRING is like Hebrew for me, I’ve learned with time
> that when I get such an error, it means that I’ve most probably omitted or
> mistyped some punctuation mark somewhere. However, PHP is unable to tell me
> where exactly is the error: it tells only the line number, and I have to
> carefully scan the entirely line to find the place. Sometimes, I resort to
> split the offending line in several ones, so that I could get more precise
> location info.
>
> So please, let the parser tell me not only the line of the error, but also
> the column. Then, it doesn’t matter how the offending token is named if you
> know where it is.
>
> —Claude
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Ryan Jentzsch]

With over 25+ years of software development experience it was In 2016 I was
introduced to the world of PHP development.
One day I came across the most unusual of error messages
"T_PAAMAYIM_NEKUDOTAYIM" What the hell is this?!?
That I needed to waste my time to Google this is simply insane. At the time
I thought to myself that PHP deserved some of the hate. Then I came across
this gem: https://phil.tech/2013/t-paamayim-nekudotayim-v-sanity/
Please for the sake of logic and sanity replace this nonsense with
T_DOUBLE_COLON

On Wed, Jun 10, 2020, 9:14 AM G. P. B.  wrote:

>  Greetings PHP internals,
>
> Kalle Sommer Nielsen and myself are proposing to rename the
> T_PAAMAYIM_NEKUDOTAYIM
> token into the already existing T_DOUBLE_COLON alias,
> T_PAAMAYIM_NEKUDOTAYIM would then become an alias to T_DOUBLE_COLON.
>
> The RFC is located here:
> https://wiki.php.net/rfc/rename-double-colon-token
>
> Although this token is a nod to the valuable contributions made by the
> Isrealie community we believe this token is rather confusing for newcomers.
> Moreso, as PHP is for many people their first programming language,
> they may not have some of the habits like googling errors when
> they are stuck, which leads to a frustrating experience.
>
> As we believe PHP still has many years of existence we think it is time
> to rename this token.
>
> This is backwards compatible with PHP 7 and 5.
> This RFC does not lay out a plan for deprecating T_PAAMAYIM_NEKUDOTAYIM
> and leaves this as a future scope.
>
> As the matter on hand is a relatively straight forward yes/no vote we
> expect
> it to be held after the minimum 2 week discussion period.
>
> Best regards
>
> George Peter Banyard
>

Re: [PHP-DEV] [RFC] Nullsafe operator

[Ryan Jentzsch]

BIG THUMBS UP for this feature.
As was mentioned that TypeScript uses this and saves developers lots of
time by avoiding nested null checking.
I suggest in the RFC including a list of other languages that have this
feature.

On Tue, Jun 2, 2020, 2:53 PM Ilija Tovilo  wrote:

> Hi internals
>
> I'd like to introduce another RFC I've been working on:
> https://wiki.php.net/rfc/nullsafe_operator
>
> It introduces the nullsafe operator ?-> that skips null values when
> calling functions and fetching properties. In contrast to the last few
> attempts this RFC includes full short circuiting.
>
> Let me know what you think.
>
> Ilija
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Ternary operator associativity

[Ryan Jentzsch]

Is there a possibility this can be fixed in version 8? From
http://phpsadness.com/sad/30 listed as an outright bug (I don't have
the C skills to fix this. I am just raising this as an issue that has
been a criticism of PHP for many years now with a new major version
upcoming that could allow for a b/c of this significance to improve
the language):

The ternary operator is left-associative and therefore behaves
entirely incorrectly:

$ cat ternary.php


$ php ternary.php
c
b
b
b

In any other language with a ternary operator, you can stack them and
build an if-elseif-elseif-else expression:

$ cat ternary.pl
#!/usr/bin/perl -w
use strict;

print +(0 ? "a" : 0 ? "b" : "c")."\n";
print +(0 ? "a" : 1 ? "b" : "c")."\n";
print +(1 ? "a" : 0 ? "b" : "c")."\n";
print +(1 ? "a" : 1 ? "b" : "c")."\n";

$ perl ternary.pl
c
b
a
a

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

Re: [PHP-DEV] print with newline

[Ryan Jentzsch]

With semantic versioning b/c is allowed. For example version 8.0.0 vs 7.x.x
-- version 8.0.0 could include major breaking changes (since it is a major
version number change).  This allows a language to evolve and grow with the
needs of the users.
If PHP is so `rigid` that NO B/C are allowed (regardless of major version
changes) then PHP is overtly rigid and I predict it will ultimately become
extinct.

On Sun, Mar 3, 2019 at 3:34 AM Thomas Hruska 
wrote:

> On 3/3/2019 1:45 AM, Ryan Jentzsch wrote:
> > Thanks for the explanation of b/c. I didn't know PHP is this rigid. Now I
> > do...
>
> It has to be.  Hundreds of millions of lines of code written in PHP run
> on millions of servers globally every single day.  The PHP devs take
> their responsibilities seriously.
>
> If it were a smaller, less widely used language, BC changes would be
> easier to make and have fewer consequences.
>
> --
> Thomas Hruska
> CubicleSoft President
>
> I've got great, time saving software that you will find useful.
>
> http://cubiclesoft.com/
>
> And once you find my software useful:
>
> http://cubiclesoft.com/donate/
>

Re: [PHP-DEV] print with newline

[Ryan Jentzsch]

Thanks for the explanation of b/c. I didn't know PHP is this rigid. Now I
do...

On Sun, Mar 3, 2019 at 1:30 AM Alexandru Pătrănescu 
wrote:

> Steven, Ryan,
>
> Adding new functions is also considered BC break because users might have
> those functions in their code.
> Over the years new functions were added to PHP core but mostly there were
> functions that saved in the userland code more than one line of code.
> Like array_first_key was accepted but array_first_value didn't.
>
> And would you all stop with PHP_EOL? If my code will ever run on something
> different than Linux, I want it to be portable, not generate files
> differently. I think we should define PHP_EOL_N constant so people will use
> it more...
>
> Jokes aside, each case might need a different version of they println/say
> implementation.
> Maintaining it in core is probably not worth the effort as it could be more
> easily maintained in userland.
>
> You can use https://packagist.org/packages/print/ln in the meantime. Or
> publish you own and use it.
>
> Regards,
> Alex
>
> On Sun, Mar 3, 2019, 08:49 Joe Watkins  wrote:
>
> > Sara, where do I send pull requests?
> >
> >  > function println(string $format, ...$args) : void {
> > \vprintf($format . \PHP_EOL, $args);
> > }
> >
> > function fprintln($stream, string $format, ...$args) : void {
> > if (!\is_resource($stream)) {
> > throw new \TypeError(\sprintf(
> > "Argument 1 passed to %s expected to be a resource, %s
> given",
> > __FUNCTION__,
> > \is_object($stream) ?
> > \sprintf(
> > "instance of %s", \get_class($stream)
> > ) : \gettype($stream)));
> > }
> >
> > \vfprintf($stream, $format . \PHP_EOL, $args);
> > }
> >
> > function sprintln(string $format, ...$args) : string {
> > return \vsprintf($format . \PHP_EOL, $args);
> > }
> >
> > Jokes aside, this is so trivially achievable in userland that there is no
> > justification whatever for an internal function or functions, or
> > constructs, or opcodes.
> >
> > Cheers
> > Joe
> >
> > On Sun, 3 Mar 2019 at 06:50, Ryan Jentzsch 
> > wrote:
> >
> > > I've always wondered why PHP didn't have a built in command or function
> > > that behaved as `echo` but with a EOL.
> > > I propose not to modify `print` or `echo` (as this was rightly pointed
> > out
> > > to cause b/c). How difficult would it be to add a new statement and/or
> > > function to the PHP core called `say` / `say()` that has an EOL?
> > >
> > > This seems to me to be simple to do. The benefit is less code to type
> in
> > > user land (ex: `say 'Hello World';` as opposed to `echo 'Hello World' .
> > > PHP_EOL;`
> > >
> >
>

Re: [PHP-DEV] print with newline

[Ryan Jentzsch]

I've always wondered why PHP didn't have a built in command or function
that behaved as `echo` but with a EOL.
I propose not to modify `print` or `echo` (as this was rightly pointed out
to cause b/c). How difficult would it be to add a new statement and/or
function to the PHP core called `say` / `say()` that has an EOL?

This seems to me to be simple to do. The benefit is less code to type in
user land (ex: `say 'Hello World';` as opposed to `echo 'Hello World' .
PHP_EOL;`

Re: [PHP-DEV] Better types without runtime checking

[Ryan Jentzsch]

Thanks Rowan for the detailed explanation.
I thought that leveraging `__get` / `__set` internally would have addressed
many of the type checking issues that you mentioned.
I've used __get/__set in userland to enforce property types and hoped that
an internal C based solution would something that is reasonable to code and
implement.

Also, can anyone in internals respond to this inquiry?
https://github.com/php/php-src/pull/1797#issuecomment-394434391


On Wed, Jun 6, 2018 at 4:00 AM Rowan Collins 
wrote:

> On 6 June 2018 at 07:14, Ryan Jentzsch  wrote:
>
>> Why would something like this not work?
>>
>> strict class MyClass
>> {
>> protected int $foo = 1;
>> public string $bar = "strict keyword in front of class
>> allows/enforces strict properties";
>> private string $isItReallyThatDifficult = "to implement this?";
>> }
>>
>
>
> The problem is not in defining what code has type annotations, it's what
> to do with them afterwards.
>
> The performance hit comes from the fact that *every* time you run:
>
> $foo->bar = $baz;
>
> The engine now needs to check whether $foo is a class with type
> constraints, and what the type constraint of bar is, and whether the type
> of $baz matches that constraint. The answer will be "no constraint" most of
> the time, but it doesn't know that until it checks, at run-time, every time.
>
> Nor is it just straight-forward assignments that would need to change,
> there are knock-on effects across the language, such as assignment by
> reference:
>
> strict class MyClass
> {
> public int $foo;
> public string $bar;
> }
>
> $a = new MyClass;
> $inst =& $a->foo; // If this is allowed...
> $inst = 'bad'; // ...then this needs to error
>
> $s = 'good';
> $a->bar =& $s; // And if this is allowed...
> $s = 42; // ... then this needs to error
>
> The previous proposal for typed properties simply raised errors when you
> tried to use reference assignment with any typed property, which feels like
> an arbitrary restriction to me. The alternative is to allow *every variable
> in the language* to carry type constraint information. I mused some more on
> this here: http://rwec.co.uk/q/php-type-system
>
> In short, yes, it really is that difficult.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Better types without runtime checking

[Ryan Jentzsch]

Why would something like this not work?

strict class MyClass
{
protected int $foo = 1;
public string $bar = "strict keyword in front of class allows/enforces
strict properties";
private string $isItReallyThatDifficult = "to implement this?";
}

On Tue, Jun 5, 2018 at 4:17 PM, Rowan Collins 
wrote:

> On 05/06/2018 08:22, Rudolph Gottesheim wrote:
>
>> There's always a lot of talk about types in the PHP community.
>> Specifically, many developers want property types, generics, function
>> signature types, union and intersection types, and more. Those talks (and
>> RFCs) always end with the same result: "We can't do it because performance
>> issues."
>>
>> Has there ever been a discussion about adding some of those features
>> syntactically, but ignoring them during runtime? At least until someone
>> finds a performant way to check them at runtime. That way we could have
>> advanced type checking in our editors at least.
>>
>
>
> Hi,
>
> I believe this is part of the original aim of Hack-Lang: the additional
> type features of that language are not part of the run-time, but checked by
> a static analysis tool offline. A number of languages have similar setups -
> Python and Dart both have the types as offline and/or development-mode-only
> features. Indeed, PHP seems to have gone a very unusual route in having a
> dynamic language with type constraints which are effectively always-on
> assertions.
>
> One of the problems with moving PHP to this offline-checking model is that
> people will expect new type constraints to work like existing ones, so may
> be caught out by them not being checked at run-time. Worse, static checks
> may not be able to detect certain violations; I don't know much about
> Hack's model, but I understand it includes both different levels of
> strictness, and restrictions on dynamic language features - things like
> references, "variable variables", and non-object callables.
>
> I do think it's an interesting question to think about though.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Ryan Jentzsch]

In my opinion The Strong Typing Syntax RFC will have less of a chance of
passing a vote than https://wiki.php.net/rfc/typed-properties.
Since the typed-properties RFC was confined to properties on a class (and
looking at the code it appears to me that it wasn't too difficult to
implement the type strictness constraints). Sadly, even after it was shown
to have minimal effect on performance the RFC was still shot down.

Strong Typing Syntax I would think is even more complicated given this
touches ALL zval processing internally. The concern of "expensive run-time
checks" can of course be mitigated by requiring declare(strict_types=1) to
enable/allow strong typing syntax.
I'd love to see Strong Typing Syntax in PHP but realistically, given the
past history, this RFC will need to target version 8.


On Wed, Jan 10, 2018 at 12:25 PM, Andreas Hennings 
wrote:

> Whether we work with runtime type checks or compile-time static analysis:
> The user-facing language design questions would still be the same, right?
> E.g. we would still have to distinguish type-locked parameter values
> vs dynamically typed parameter values.
>
> On 10 January 2018 at 20:23, Andreas Hennings  wrote:
> > On 10 January 2018 at 19:59, Rasmus Lerdorf  wrote:
> >>
> >> Now if the RFC was a plan for baking a compile-time static analysis
> engine
> >> into PHP itself, that would be interesting. But that is a *massive*
> project.
> >
> > Even with my limited understanding of the engine, I can imagine this
> > to be a lot of work.
> > But it sounds much better to me than adding more expensive runtime type
> checks.
> > I think it would be worth exploring as a long-term direction.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Ryan Jentzsch]

I agree with Michael (to a large degree) and I think I see clearly
Michael's point:
Under the current system I will NEVER create an RFC (or find someone with
the Zend engine coding chops to help me) because the RISK vs. REWARD with
the current RFC system is too likely to be a colossal waste of everyone's
time.
Currently the tail wags the dog (implementation details govern top level
policy). The current process nearly insists I spend valuable time coding up
front with a good chance that if/when the RFC goes up for a vote someone
will still be bleating about syntax, or using tabs vs. spaces, or some
other minor detail -- with a 2/3 vote needed it may shoot all my
preliminary hard work to hell. No thanks.



On Wed, Jan 10, 2018 at 6:27 AM, Michael Morris  wrote:

> On Wed, Jan 10, 2018 at 12:53 AM, Rasmus Lerdorf 
> wrote:
>
> >
> > The difference here is that the end syntax is something like 10% of the
> > problem. 90% of it is fitting it into the engine in an efficient manner
> > giving that it is affecting the very core of the engine. An RFC on this
> > issue that doesn't address the bulk of the problem isn't all that
> helpful.
> >
> >
> It makes absolutely NO sense to do that 90% of the work to have it all
> burned up when the proposal fails to carry a 2/3rds vote because the syntax
> is disliked.
>
> Also, drawing the architectural drawings for a skyscraper is also like only
> 10% of the work, but it's a damn important 10%.
>
> That the implementation will be a major pain in the ass to do is all the
> more reason to create and pass a planning RFC before doing any related
> code/implementation RFC's. It will encourage people to do the research to
> try to figure out how to get this done because they know the syntax is
> approved and they aren't fiddling around in the dark trying to figure out
> how to do something that may not be accepted for inclusion at all, which is
> a huge waste of time.
>

[PHP-DEV] The site bugs.php.net appears to be down

[Ryan Jentzsch]

I am trying to look up and/or enter a bug report:

downforeveryoneorjustme.com reports:
  Is bugs.php.net down?
  It's not just you! bugs.php.net looks down from here.

[PHP-DEV] Easy method of overriding built-in php functions.

[Ryan Jentzsch]

I am aware of Advanced PHP debugger but what I need this type of
functionality for is mocking and testing.

As an example I want to use PHPUnit mocking feature to create a mock of a
class. However in the constructor of this class is the following line to
get the expected JSON string:

$result = file_get_contents('php://input');

I can not override the file_get_contents() function. The work around is to
monkey patch the class as a mock and override the constructor (copying ALL
logic from the constructor to the mock allowing for $result to be taken
from the constructor's argument list).

This is awkward and in my use case the constructor also makes calls to
static methods in other objects which the latest version of PHPUnit does
not allow you to mock static methods.

ADP is not acceptable to override functions in that it requires a binary to
be installed and php.ini to be configured as well as no support for this in
Windows.

Is there an RFC that I didn't find that allows for easily overriding
built-in functions? For example:

@function file_get_contents($string)
{
return 'mock string';
}

My C skills are quite rusty and understanding the Zend engine is a daunting
task or I'd create an RFC myself. The devil is in the details. The real
question I am asking is HOW DIFFICULT would something like this be to code
and include in the PHP core?

Re: [PHP-DEV] json_encode() / json_decode() warnings

[Ryan Jentzsch]

I can't count how many times I've been bitten by this. From the infamous
fractal blog:

"Parts of PHP are practically designed to produce buggy code.
json_decode returns null for invalid input, even though null is also a
perfectly valid object for JSON to decode to—this function is completely
unreliable unless you also call json_last_error every time you use it."

Most functions in PHP return false as an indicator for an invalid call.
json_decode() returns null -- changing this to return false is also a
breaking change that may not survive a vote.

Because of the unreliability I don't use this function and always rely on
3rd party JSON libraries instead.

On Fri, Jul 28, 2017 at 12:59 AM, Niklas Keller  wrote:

> 2017-07-28 8:56 GMT+02:00 Giovanni Giacobbi :
>
> > On 27 July 2017 at 18:00, Craig Duncan  wrote:
> >
> >> On 27 July 2017 at 16:57, Niklas Keller  wrote:
> >>
> >> > It should rather just throw exceptions. Warnings do not really allow
> >> error
> >> > handling, they just allow error reporting.
> >> >
> >> >
> >> Agreed, but I can't see Exceptions passing the vote. Warnings can be
> >> silenced by those that don't care and converted to Exceptions by those
> >> that
> >> do
> >>
> >
> > Error management is a painful topic in PHP, expecially when considering
> to
> > the way fopen() behaves, where you *need* to use the "@" suppression if
> > you want it to behave the way you expect it to behave.
> >
> > About Exceptions you can easily build a framework around core functions,
> > for example this is in my core library for all projects:
> >
> > ```php
> > function safe_json_decode($json = null) {
> >   if ($json == "")
> > return null;
> >
> >   $retval = json_decode($json, true, 512, JSON_BIGINT_AS_STRING);
> >   if (json_last_error() != JSON_ERROR_NONE)
> > throw new JsonDecodeException(json_last_error_msg(),
> > json_last_error());
> >
> >   return $retval;
> > }
> > ```
> >
> > So yes, the behaviour of json_decode() might not be optimal, but it's
> fine
> > the way it is.
> >
>
> Yes, I know. There's https://github.com/DaveRandom/ExceptionalJSON.
>
> While the current API works, I'm not sure whether I'd say its fine.
>
> Regards, Niklas
>

Re: [PHP-DEV] Bundled libraries upgrade 'process'

[Ryan Jentzsch]

This may be a dumb question...I was under the impression that including the
config switches for the databases such as MySQL, SQLite, Postgres, etc.
that ONLY the PDO bindings are included NOT the database client itself.

Is this the case with the exception of SQLite? In other words is the
version of MySQL that is bundled with PHP also built when I build from
source? Or am I misunderstanding this whole issue?

- Ryan



On Mon, Jul 17, 2017 at 8:12 AM, Dan Ackroyd  wrote:

> Hi Internals,
>
> I just investigated an alleged bug related to the SQLite3 extension.
> It seems this bug occurs when PHP is compiled with the current bundled
> SQLite files, which are a little out of date as they are version:
> "3.15.1", date: "2016-11-04".
>
> Listed at https://sqlite.org/changes.html there are multiple versions
> that SQLite could be upgraded to.
>
> * 2016-11-28 (3.15.2) - small bugfix upgrade.
> * 2017-06-08 (3.19.3) - bigger upgrade that has performance improvements.
>
> Questions:
>
> 1. Do we have a process for deciding whether to upgrade bundled libraries?
>
> 2. Can anyone see anything in the release notes that would be a
> problem for upgrading past 3.15.2 ?
>
> 3. Do we have a process for getting feedback from users about whether
> a proposed upgrade would cause problems, other than doing the upgrade
> and shipping it?
>
> I can't see anything listed in the SQLite release notes that would
> cause a problem.but that's obviously not the same as being sure an
> upgrade wouldn't cause problems.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>