[PHP-DEV] Re: [RFC] Change default PDO error mode

[Andrea Faulds]

Hi,

AllenJB wrote:

I present for discussion an RFC to change the default PDO error mode:

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


A good thing about this RFC is that if you prefer the traditional error 
mode and need to keep that behaviour working in whatever new PHP version 
hypothetically implements this RFC, adding the call to set the error 
mode will not make your code incompatible with previous PHP versions, 
which means it should be tolerable for the authors of libraries or other 
software packages. :)


Thanks,
Andrea

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

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

[Sherif Ramadan]

On Fri, Apr 3, 2020 at 5:16 PM Andrea Faulds  wrote:

> Hey Sara,
>
> Sara Golemon wrote:
> > On Mon, Mar 30, 2020 at 12:38 PM Chase Peeler 
> wrote:
> >
> >> Just out of curiosity, is there any reason we couldn't add an optional
> >> parameter called "$short_array" or whatever that defaults to false? Then
> >> there shouldn't be any backwards compatibility issues.
> >>
> >> None at all, though I'd make it an `int $options = 0` similar to
> > json_encode().  I'd have a FAR easier time supporting that than a
> wholesale
> > BC break for the sake of breaking BC.
> >
> > I can think of a few options:
> >VAR_EXPORT_SHORT_ARRAY => use [] instead of arrray()
> >VAR_EXPORT_NO_WHITESPACE => Keep it concise, single line
> >VAR_EXPORT_NO_VECTOR_INDEX => If an array is vector-like, skip indexes
> >VAR_EXPORT_UTF8_UESCAPE => Detect places where we can use \u{1234}
> syntax
> > for UTF8 strings
> >
> > Though I'm going to stay with my stated position that I would MUCH rather
> > this stuff live in userspace.  Just because PHP's penchant for
> > including the kitchen sink is broken already doesn't mean we should break
> > it more.
>
>
+1 for me


> As you say, including the kitchen sink might be excessive, but I think
> adding a $flags option isn't a bad idea — it's low-maintenance, simple
> to implement and, in my opinion, would be frequently used. We can have
> the best of both worlds: consistent default behaviour, and nicer output
> for those who want it. I can see myself using VAR_EXPORT_SHORT_ARRAY and
> VAR_EXPORT_NO_VECTOR_INDEX (not with that name…) :)
>

*Fingers crossed*


> (Also, if we make the output of var_export() more palatable, will people
> use it instead of print_r() for development purposes? I can dream…)
>
> Thanks,
> Andrea
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

[Andrea Faulds]

Hey Sara,

Sara Golemon wrote:

On Mon, Mar 30, 2020 at 12:38 PM Chase Peeler  wrote:


Just out of curiosity, is there any reason we couldn't add an optional
parameter called "$short_array" or whatever that defaults to false? Then
there shouldn't be any backwards compatibility issues.

None at all, though I'd make it an `int $options = 0` similar to

json_encode().  I'd have a FAR easier time supporting that than a wholesale
BC break for the sake of breaking BC.

I can think of a few options:
   VAR_EXPORT_SHORT_ARRAY => use [] instead of arrray()
   VAR_EXPORT_NO_WHITESPACE => Keep it concise, single line
   VAR_EXPORT_NO_VECTOR_INDEX => If an array is vector-like, skip indexes
   VAR_EXPORT_UTF8_UESCAPE => Detect places where we can use \u{1234} syntax
for UTF8 strings

Though I'm going to stay with my stated position that I would MUCH rather
this stuff live in userspace.  Just because PHP's penchant for
including the kitchen sink is broken already doesn't mean we should break
it more.


As you say, including the kitchen sink might be excessive, but I think 
adding a $flags option isn't a bad idea — it's low-maintenance, simple 
to implement and, in my opinion, would be frequently used. We can have 
the best of both worlds: consistent default behaviour, and nicer output 
for those who want it. I can see myself using VAR_EXPORT_SHORT_ARRAY and 
VAR_EXPORT_NO_VECTOR_INDEX (not with that name…) :)


(Also, if we make the output of var_export() more palatable, will people 
use it instead of print_r() for development purposes? I can dream…)


Thanks,
Andrea

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

Re: [PHP-DEV] Understanding RFC attitudes

[Chase Peeler]

On Fri, Apr 3, 2020 at 12:38 PM Dan Ackroyd  wrote:

> Hello Internals,
>
> The trade-offs that are good for a project like core PHP are quite
> different from the trade-offs from other projects.
>
> People are sometimes quite surprised by the attitude other people have
> on how best to maintain and improve PHP.
>
> I'm hoping that documenting my understanding of the attitudes that
> have been taken during RFC discussions, might avoid some of the
> surprise factor in discussions and so make the conversations be less
> confrontational.
>
> https://github.com/Danack/RfcCodex/blob/master/rfc_attitudes.md
>
> To be clear, this is only meant to help people understand other
> people's view-points. It is not a fixed set of attitudes that I think
> either are or should be followed.
>
> It's also not aimed at making everyone agree on all topics, but just
> to help set people's expectations on how any particular RFC might be
> received.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I think this is a good idea. It appears to be a fair overview of various
topics. Personally, instead of organizing it into the two main areas that
you did, I think it would be better to maybe just list the various types of
arguments used for/against RFCs, and what the pro/con positions are. As it
is currently written, anything in the "less likely to pass" section might
be taken as something that should be avoided - even in cases where such
things do make sense. If, instead, we lay it out as "If you propose this,
these are the arguments you're going to get as objections, and here are
some of the justifications that have been used so far" someone might better
be able to determine if their RFC for such a topic is justifiable, and if
so, preempt some of the objections.

-- 
Chase Peeler
chasepee...@gmail.com

[PHP-DEV] Understanding RFC attitudes

[Dan Ackroyd]

Hello Internals,

The trade-offs that are good for a project like core PHP are quite
different from the trade-offs from other projects.

People are sometimes quite surprised by the attitude other people have
on how best to maintain and improve PHP.

I'm hoping that documenting my understanding of the attitudes that
have been taken during RFC discussions, might avoid some of the
surprise factor in discussions and so make the conversations be less
confrontational.

https://github.com/Danack/RfcCodex/blob/master/rfc_attitudes.md

To be clear, this is only meant to help people understand other
people's view-points. It is not a fixed set of attitudes that I think
either are or should be followed.

It's also not aimed at making everyone agree on all topics, but just
to help set people's expectations on how any particular RFC might be
received.

cheers
Dan
Ack

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

Re: [PHP-DEV] [RFC] Allow trailing comma in parameter lists

[Ryan McCullagh via internals]

This would make PHP more consistent. Please add this!

On Mon, Mar 30, 2020, at 12:32 PM, Guilliam Xavier wrote:
> On Sun, Mar 29, 2020 at 11:31 PM Jakob Givoni  wrote:
> >
> > Hi Rowan,
> >
> > On Sat, Mar 28, 2020 at 4:01 PM Rowan Tommins  
> > wrote:
> > >
> > > While I'd personally be fine with this change, I think we should
> > > understand why the previous proposal failed rather than just hoping the
> > > vote goes differently this time.
> >
> > I think you have a good point here.
> > I've only been around for a short time so I can't comment on historical 
> > reasons.
> > And though I agree the proposal is logical and consistent, I have this
> > nagging feeling in the back of my brain:
> > Are we encouraging functions with long lists of parameters so that
> > they need to be on their own lines?
> 
> Just to say, with descriptive names and type declarations (and now
> union types), even a method with just two or three parameters can need
> to be wrapped to keep lines below 120 characters ;) Maybe the RFC
> could include an example?
> 
> But I am curious too about why it failed last time.
> 
> -- 
> Guilliam Xavier
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
>

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

[PHP-DEV] Re: [VOTE] Server-Side Request and Response Objects (v2)

[Paul M. Jones]

> On Mar 20, 2020, at 08:31, Paul M. Jones  wrote:
> 
> Hi all,
> 
> I have opened the vote on Server-Side Request and Response Objects at 
> .
> 
> The voting period will close two weeks from today on Fri 03 Apr 2020.

The vote is now closed; at 11 in favor to 35 against, the RFC is not accepted.

I will try to put together an after-action/lessons-learned message next week.

Thanks to all who participated.


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

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

Re: [PHP-DEV] [RFC] Stricter type-checks for arithmetic/bitwise operators

[Nikita Popov]

On Thu, Apr 2, 2020 at 3:11 PM Rowan Tommins 
wrote:

> Hi Nikita,
>
> On Thu, 2 Apr 2020 at 09:14, Nikita Popov  wrote:
>
> > I would like to propose making the use of arithmetic/bitwise operators on
> > arrays, resources and (non-overloaded) objects a TypeError exception:
> >
> > https://wiki.php.net/rfc/arithmetic_operator_type_checks
> >
>
>
> Thanks for writing this up; one of the conclusions when revising my inc/dec
> RFC was that this should be proposed, but I've not had the energy to follow
> through.
>
> Discovering that objects become int(1) was a big WTF for me. I'd happily
> see that throw an error even under an explicit cast - "(string)new class{}"
> is currently an Error, but "(int)new class{}" and "(float)new class{}" are
> only a Notice.Would it be possible to throw an Error in this case without
> fixing the comparison operator quirk you noted in rfc/engine_warnings?
>

In preparation for this change, I've decoupled the error reporting from the
cast logic, so it is now possible to make just the cast throw, without
influencing comparison. However, there might be exception safety concerns,
along the same lines as https://wiki.php.net/rfc/tostring_exceptions for
the string cast case.

Nikita


> I initially thought resources made sense as they are, but like you I
> concluded that the only real use is to get the ID itself, so explicit casts
> are enough. There's a possibility that someone used to JS might write
> $resource+0 instead of (int)$resource out of habit, but it doesn't seem
> particularly likely, and is easy to fix. get_resource_id() is a good idea,
> too; for similar reasons, I've often wished objects with __toString()
> aliased it to a more specific method, rather than it being the only way to
> get a certain representation.
>
> While the behaviour of other types such as strings would be nice to
> revisit, I think it's worth keeping this RFC to arrays, objects, and
> resources, because other cases have a lot more to consider in terms of
> detail and backward compatibility impact.
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>

[PHP-DEV] Memorizing zval objects

[Joseph Montanez]

I've been working on a PHP extension, binding RayLib. One issue I am
running into is that objects are being freed, which is triggering things I
don't want trigger until completely dereferenced.

So I have the following lines of PHP code:

$font = Font::fromCustom(__DIR__ . "/resources/KAISG.ttf", 96, 0, 0);
$font->texture->genMipmaps();

Font is a struct from RayLib that I am trying to mirror into a PHP class
with properties. Here is the RayLib C Struct:

typedef struct Font {
int baseSize;   // Base size (default chars height)
int charsCount; // Number of characters
Texture2D texture;  // Characters texture atlas
Rectangle *recs;// Characters rectangles in texture
CharInfo *chars;// Characters info data
} Font;

The issue is every time I call $font->texture and the result $texture
object is not store, then its deference and the Texture object free
function is called, which unloads the texture, even though the Font struct
is still needing it. This is my fault as every time $font->texture is
called, I create a brand new texture object:

static zval * php_raylib_font_texture(php_raylib_font_object *obj) /* {{{ */
{
zval *texture = malloc(sizeof(zval));
object_init_ex(texture, php_raylib_texture_ce);

php_raylib_texture_object *result = Z_TEXTURE_OBJ_P(texture);
result->texture = obj->font.texture;

return texture;
}
/* }}} */

So after this line:
$font->texture->genMipmaps();

A Texture object is created, and right dereferenced thus calling my free
logic

void php_raylib_texture_free_storage(zend_object *object TSRMLS_DC)
{
php_raylib_texture_object *intern =
php_raylib_texture_fetch_object(object);

zend_object_std_dtor(>std);

UnloadTexture(intern->texture);
}

So I assume I need to start storing the texture object, on my Font object.
Currently, it's defined like this:

typedef struct _php_raylib_font_object {
Font font;
HashTable *prop_handler;
zend_object std;
} php_raylib_font_object;

Am I to add another zend_object, zval or the struct def for Texture? I.E

typedef struct _php_raylib_font_object {
Font font;
HashTable *prop_handler;
zend_object texture; // Do I use zend_object?
zval texture; // Do I use zval?
php_raylib_texture_object texture; //Do I use the struct defined for
texture?
zend_object std;
} php_raylib_font_object;

For reference here is the Texture header:
https://github.com/joseph-montanez/raylib-php/blob/master/raylib-texture.h

Thanks,
Joseph Montanez