Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

[Thomas Nunninger]

Hi,

Am 02.08.24 um 18:51 schrieb Ilija Tovilo:

...

There are a few noteworthy downsides:

* Unqualified calls to functions in the same namespace would be
slightly slower, because they now involve checking global scope first.
I believe that unqualified, global calls are much more common, so this
change should still result in a net positive. It's also possible to
avoid this cost by adding a `use function` to the top of the file.
* Introducing new functions in the global namespace could cause a BC
break for unqualified calls, if the function happens to have the same
name. This is unfortunate, but likely rare. Since new functions are
only introduced in minor/major versions, this should be manageable,
but must be considered for every PHP upgrade.
* Some mocking libraries (e.g. Symfony's ClockMock [5]) intentionally
declare functions called from some file in the files namespace to
intercept these calls. This use-case would break. That said, it is
somewhat of a fragile approach to begin with, given that it wouldn't
work for fully qualified calls, or unnamespaced code.


Similar to Symfony's ClockMock this "feature" was propagated some years 
ago to e.g. intercept calls to the file system when running tests where 
the application was not designed with test-ability in mind.


Regards,
Thomas

[PHP-DEV] Issue with php.net

[Thomas Nunninger]

Hi,

sorry, I don't know where to send this. But

When visiting https://www.php.net/ I get a certificate error: The 
provided certificate is for www.caruso.ovh.


When visiting http://www.php.net (http only), I get redirected to 
http://www.caruso.ovh/


Regards
Thomas

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

Re: [PHP-DEV] [RFC][Vote] Asymmetric Visibility

[Thomas Nunninger]

Hi,

I was looking at the current vote of this RFC and I stumbled upon 
Theodore's remark that the RFC feels unfinished as it can't be used in 
conjunction with readonly properties/classes.


The RFC disallows (for the time being) the mixing of readonly with 
explicit asymmetric visibility. And I was happy about it. Thus I didn't 
feel the need to comment about it so far.


The main motivation given in the readonly RFC was value objects. And as 
far as I understand, one of the main reasons was to reduce boilerplate 
code (esp. public getters). readonly works fine for value objects. But 
looking at entities, there is no solution so far. Thus I still (might) 
need to provide public getters. And because of the limitations of 
readonly, there was/is a need for asymmetric visibility.


I doubt, there would be any need for readonly if we would have had 
asymmetric visibility first. And (using asymmetric visibility) I assume, 
developers should be able to ensure that a property is 1. only 
initialized once, 2. inside the limited scope of a class, and 3. not 
overwritten during the lifetime of the object. I'd be interested in a 
use case where you would really like to ensure this on the engine level.


To go one step further, I would even ask the heretical question if we 
should discourage/deprecate readonly once we have asymmetric visibility. ;-)


Regards
Thomas

Am 07.01.23 um 00:37 schrieb Larry Garfield:

I am hereby opening the vote on the Asymmetric Visibility RFC:

https://wiki.php.net/rfc/asymmetric-visibility

Voting will be open for 2 weeks.

While we would certainly prefer if everyone voted in favor, for those who vote 
against the authors kindly request that you indicate why, using the second poll 
question or comment section afterward.  Thank you.



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

Re: [PHP-DEV] Casting array to any class

[Thomas Nunninger]

Hi,

Am 15.10.22 um 13:18 schrieb Gianni Gentile:

Hi,

in my every day experience, using custom DTO classes and different API, 
I often write code to instantiate my objects from associative arrays.


What are your thoughts on introduce the `(AnyType)` cast to instantiate 
objects from associative array (or object properties also)?


In my proposal, if AnyType implements __set_state(), casting should be 
syntactic sugar for:


     AnyType::_set_state((array) $data)

just for (useless) example, consider DateTime or DateTimeImmutable (both 
have __set_state() implementation); when applied to objects of that 
type, we can write:


     $dt = new DateTime();

     $dtArray = (array) $dt; // 3 elements array

     $copyOfDt = (DateTime) $dtArray; // or simply $copyOfDt = 
(DateTime) $dt;


In case AnyType does not implements __set_state(), casting should create 
a new instance, assigning values to properties, taken from array values 
with corresponding key (in a similar way class objects are created when 
row is fetched from database specifying PDO_FETCH_CLASS) eventually 
invoking __set() magic method for properties not declared;


In this scenario,

     (object) ['one' => 1, 'two' => 2]

and

     (StdClass) ['one' => 1, 'two' => 2]

do exactly the same work.


Reasons:

- clear code

- array to object conversion (casting) would be the simmetrical 
counterpart of object to array conversion



I see your use case and I often have similar needs. Some thoughts:

* Are there any restrictions regarding the matching of array keys and 
the class attributes? What if there are additional keys in the array 
that do not have corresponding attributes? What if there are some 
attributes in the class that do not exist in the array?


* Can I forbid a class to be created by casting from an array? When I 
think about domain entities/aggregates, such a casting would allow to 
create an invalid state of the object without any checks. (Okay, we have 
similar issues when recreating them from a database via some ORM.)


BTW:



Will dump with modified array keys:

/home/thomas/test.php:12:
array(3) {
  '\0A\0myPrivate' =>
  string(7) "private"
  '\0*\0myProtected' =>
  string(9) "protected"
  'myPublic' =>
  string(6) "public"
}

So it's not as symmetric as intended.

Regards
Thomas

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

Re: [PHP-DEV] Error behaviour for max_input_vars

[Thomas Nunninger]

Hi,

In summary, I believe this can only be solved inside of PHP itself, by 
allowing to configure a way for `max_input_vars` to abort the request 
instead of truncating the input.

The options I see feasible are:
- A new ini setting `max_input_vars_abort` (default to 0), which, if set 
to 1, will abort the request if there are more input variables than 
allowed.
- A method to reliably detect whether the input vars were truncated (eg. 
`function has_post_been_truncated(): bool`), so the application can 
decide whether to abort or not.
- Deciding that `max_input_vars` is not relevant anymore and should be 
handled by the likes of Apache and NGINX, thus changing the default to 
`0` and removing the setting

     over a deprecation period.

I am leaning towards the first option, but would be open to either outcome.


I'd prefer that PHP aborts such requests. Then data loss/inconsistency 
is prevented for everybody and people can fix their applications. (So no 
need for an ini setting that allows acting in "danger mode".)


If you'd like to give developers more options to choose from, I'd go for 
max_input_vars_abort (default 1) plus has_post_been_truncated(): That 
way the behavior is safe from the start. And people who opt in for 
"danger mode" can reliably detect if there was some data loss and can 
deal with it.


Regards
Thomas

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

Re: [PHP-DEV] Executing PHP SAPI/runtime from Golang/Rust

[Thomas Nunninger]

Hey,

Am 14.08.22 um 14:29 schrieb Paul Dragoonis:

Hey,

So one thing that keeps me up at night (for a while now) is resisting the
urge not to venture down a rabbithole of writing code which is loading the
PHP runtime from Rust/Golang (up to MINIT)

And then at RINIT time, we load the right SAPI and pass across the SERVER
vars that's needed for it..

Here is a use case example. Golang concurrency model on the front, and it
can execute PHP CLI SAPI or HTTP SAPI on the back.

Moreover if you're looking at reasons people have previously or currently
moving away from PHP to other languages, due to limitations like pure async
or concurrency stuff .. then perhaps a new FRONTEND which can execute the
PHP runtime on the backend would be solving some things.

I appreciate this isnt a unique idea and maybe someone else from internals
has raised this before .. but I wanted to raise the topic to check the
viability of this if it is possible, and what blockers are in our way,
currently, if it's not even possible to share SAPI calls from another
language runtime.


I'm not sure about the internals you mention. Are you looking for 
something like https://roadrunner.dev/


"RoadRunner is a high-performance PHP application server, load-balancer, 
and process manager written in Golang."


Best regards
Thomas

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

Re: [PHP-DEV] [RFC] Asymmetric visibility

[Thomas Nunninger]

Hi,
Am 05.08.22 um 19:08 schrieb Larry Garfield:

Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: 
Asymmetric Visibility.

https://wiki.php.net/rfc/asymmetric-visibility

Details are in the RFC, but it's largely a copy of Swift's support for the same.


Great to hear that there is a new and simple proposals.

One note: In the example about references, I assume the class Baz must 
extend from Foo.


Good luck with this proposal
Thomas

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

Re: [PHP-DEV] instance version of match ?

[Thomas Nunninger]

Hi,

Am 29.03.22 um 14:34 schrieb Rowan Tommins:

On 29/03/2022 11:59, Robert Landers wrote:

 $object instanceof AnotherInterface => 'bar',

We can see that `SomeInterface` will resolve the interface and not the
constant.



Yeah, the instanceof operator is magic in that regard - it has a special 
parsing rule to consume the next token and avoid it being evaluated as a 
constant.




I think what they are proposing is that when the match is an object,
and the branches are class/interface/etc names, it should just do an
`instanceof` operation instead of a value-equals operation.



That wouldn't work, because the type of value passed to match() can vary 
at run-time, but you'd need to compile the expression one way or the other.


If it did work, it would be extremely confusing:

function example(string|object $input) {
     return match($input)  {
   SomeClass => 'found class',
  SOME_CONSTANT => 'found constant',
     };
}
var_dump( example(new SomeClass) );
var_dump( example(SOME_CONSTANT) );

Do both of those matches succeed? What if I set `const SomeClass = 
'hello';`?



So unfortunately we need some extra syntax to say that something should 
be an instanceof check, and therefore a class name.


While I liked the intention of Karoly, I did not like the proposed magic.

Would it be an idea (and possible) to extend the syntax somehow like:

$result = match ($value) {
instanceof MyObject => ...,
>= 42 => ...,
!== 5 => ...
};

to be equivalent to:

$result = match (true) {
$value instanceof MyObject => ...,
$value >= 42 => ...,
$value !== 5 => ...
};


Regards
Thomas

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

Re: [PHP-DEV] Setting to disable the "Undefined array index" warning

[Thomas Nunninger]

Hi Nicolas,

as far as I understand, adding new ini settings is not the way to go as 
this would mean that your code behaves differently on different 
environments.


Two suggestions:

* Write your own error handler that ignores those errors.

* Try some tool like Rector to rewrite your code.

Best regards
Thomas

Am 15.02.22 um 13:31 schrieb Nicolas BADIA:

Hi,

As it is explained in this ticket https://bugs.php.net/bug.php?id=81417 we use 
to check if a property exists by accessing it directly like we do in JavaScript.

Personally, I subscribe to this coding style and we use it all over our 
codebase (more than 130 000 lines of PHP code). When it became a notice, we 
disabled them, but now that it is a warning, it is a lot more problematic for 
us… We can’t even use the last version of PHP Debug for VSCode.

As I’m not ready to spend weeks upgrading our codebase because our coding style 
is not supported by the community, I’m looking at alternatives.

The more obvious and simple for me would be to add a setting in php.ini to 
allow this. So I’d like to know if it is something you would support.

If not, I guess I will have to fork PHP, but this will complicate a lot our 
deployment process and make our code not portable. As I believe we are not the 
same in this case, I hope you will support the addition of a setting…

Thanks in advance for considering this.

Best regards,

Nicolas


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

Re: [PHP-DEV] PHP 8.1.0 Released!

[Thomas Nunninger]

Hey,

let's celebrate! Congrats and thanks to all who have been involved in 
creating this great new release!


Best regards
Thomas

Am 25.11.21 um 19:20 schrieb Patrick ALLAERT:

The PHP development team announces the immediate availability of PHP 8.1.0.
This release marks the latest major release of the PHP language.

PHP 8.1 comes with numerous improvements and new features such as:
- Enumerations
- Readonly properties
- Fibers
- Pure Intersection Types
- never return type
- First-class Callable Syntax
- "final" modifier for class constants
- New fsync and fdatasync functions
- New array_is_list function
- Explicit Octal numeral notation
- And much much more...

For source downloads of PHP 8.1.0 please visit our downloads page
(https://www.php.net/downloads.php), Windows source and binaries can be
found on https://windows.php.net/download/.
The list of changes is recorded in the ChangeLog
(https://www.php.net/ChangeLog-8.php#8.1.0).
The migration guide (http://php.net/manual/en/migration81.php) is available
in the PHP Manual.
Please consult it for the detailed list of new features and backward
incompatible changes.

Many thanks to all the contributors and supporters!

Release Manifest here and below:
https://gist.github.com/patrickallaert/0be0058dafafc7a669af7f6d5f39bc81

Patrick Allaert, Ben Ramsey & Joe Watkins

php-8.1.0.tar.bz2
SHA256 hash:
0725ed2baea125496a898455d501a77460218b2a0cfad773fa9322f491b82b61
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmGdObkACgkQGZ+d/vb/
uv2zAhAAh8XwQSAMOM86xbcTScnAyhHSSTtujaCH/vUMOEsdE1a/fc0a0lAwW4T1
/IFF/0+GLpOBq827KtG8DrklNBnnc3wOwGWrBu55timNWuT5vuwFuOqExf2Nrlw3
Pxz1rQ1CbCkEsBr8gF74/Tw5MS8fay+Oq0FXqHPLfL/8/oBBmpPsddR/0ycFB7PP
K1OVnpRwfq3UanVOUxOQxfsR86sGsldNn6y8iv2N2D/Mq8Qxjeu1ZAy34gwytUW3
g0XxcXAYA23KwWuDM9S4zdSTjh5cGCzbt3ueRXC59ar3wNkL8dAQlytlyWT1U8B+
OCCp/Nc94ebNXZFe0TfltMgpepjOYkJw33MzJC3K3EgAeUI4zzgB38CS8ekYExDq
VtTW9edUCt1SBXbsoX910QyU5O4HWA84qc80Jk2Qoiong7IRnotHDsf8pAzDeg3L
MSCxU8syPieMRiS1eYaFXV+DRY8ByiGuOLtMeh00OSMkXGK6QP7x31XKs+SbVli9
Pen4KR4X3mNQ3akAM5qSMiHkzitZXhjtcu9guuwgzinBhJENIEQlKbvmDVAUjWlF
uPdHPby9Ip33sL8ZCRs3YQUofz3DaGbxZqDu801yUzYjWG/f2IXauU7QUkMiZ1yY
rbRoO/YMLy8rz80rOK8tAS3GiyxVn5hR2Fcgsks9za0ZXx8oQA4=
=7J12
-END PGP SIGNATURE-

php-8.1.0.tar.gz
SHA256 hash:
848705043ea4a6e022246ae12a1bff6afcf5c73ea98c6ac4d2108d6028c5c125
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmGdObkACgkQGZ+d/vb/
uv39wg//Yfy45SiTS/72gTQhZhX0ssSeMHuYh5Uv2GLtb5HrzpYmaJYfUKs5SS3r
Ztik7sV8HclvRfy1wZGv4TkFPrptxjXXSpvrXaLKRb4qqN4XUtD1MpuX11BUrX9S
J2izARb/OK9+NNn1zuQ0gPC3gjdE4RvUP9DOv3DcDktg91itaUWeM4/B4o1RCQlk
H2UPmVE4ZX5QZrAY1TDjuxDpT5N32piLHPR6/oO/iTb5Y9vBLDH0qYVG1wlrwtH4
B2JDLnvN1B1Ta4t4wbR3EgpKkMP4VTAbcnTbM7fm0kHB8at6RZCFbroLoz8BpLGi
oHGPFIDrbswn26Vtgb7hH7SpaD3ZbXi3sc0x0kSbyPScS2LOpSoCH4xbTR090VAK
1hbsZBMszTu3sI089EHzWaQ6FuPQONXONEKzSOG7WWk7Y1alfhjUMuRNTQHIxj0R
xjIzHK8N71RWK3qJkPloQKZwCC83saNAWknj+w0oO5JNvt6NHobPJzBogfmZqFov
VYqQFrvG/Vy0ff3tGrpvQkSyUvNtsvL50lY8CCj37OJ0H0XiVHbZxblvBU6hFGgN
bU6+wN7fmm++iS9Jk39qsIGzsFB1MWKqwcUdrkvUo04U5HfFtpoko6hqGldYKpxh
QUktAat9U2n/DtHAcscUzs8odrN9hRnvi2ENIURrsM3EWYYJZYU=
=kUBK
-END PGP SIGNATURE-

php-8.1.0.tar.xz
SHA256 hash:
a1317eff0723a2b3d3122bbfe107a1158570ea2822dc35a5fb360086db0f6bbc
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmGdOboACgkQGZ+d/vb/
uv29OQ/+MTwutRkruh5cqqrfCsAHUq8zaIsb5e2aQnaOhVZ93S/tfEKxQjVaGLyQ
6D0eZtToCr/yGE3LCl5514OpgF2yf6Nvpx1xtHlVcsYY94ULChBTDGyng7wlxRx3
aAZRBNqUHtVCN/ZluzCndcbc32j05ukIjFLYM3OuEY9pK7DbrW+EAt4LA67uffSL
0pdrFTVNVFvUsoykN40rixCR4vDyAGocHOq90MjYj/VBy/1I9wN87pV55qt3E9xw
XnYX6M3ZZHeaqmiDv7EcN7vf47qtbmQM5XEn5iUnFDY6HCyLkvjgkTNJhY9FrXxp
4ciRWzTbzHQ+8TF8SG3CVdFnTe1rTAtHvorq4A6VV7FB7zeAvkTJNLaIfs6/YULp
hMLk6A/N/gGpM7qgJwgB2Cg2DGOYyHK0dxJ1l5CaRIFOT2xBSUI5O3YdC40o7UyD
Zh3iN7X8aLCcfqCdGgBlVaIjLCMvhqtlJU3JKMlp3A3cgXlyRcr72eT3lBH3J/QE
UZECfudsHFzNdE6FZu0sVTm+oDd7CHPJboS06CuwcuElxHZHhS9e6kfmNvNTBw6g
8vHDS5tq8kqiox8R1sSGN9gCSH1EkI2Em+G0JFouTap2/UNl8/jCcvdKL+kdjydH
TQs21fi59WE7BXJjymbnUozLRx3owLmDxo3U9IInUKwRLUnYmZU=
=jy/h
-END PGP SIGNATURE-


>

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

Re: [PHP-DEV] BC breaking changes in PHP 8.1

[Thomas Nunninger]

Hi,

Am 22.09.21 um 15:29 schrieb Matthew Weier O'Phinney:

Here's the issue: while overall, I like the move to resource objects,
introducing them in a MINOR release is hugely problematic.

Previously, you would do constructs such as the following:

 if (! is_resource($resource) || get_resource_type($resource) !==
$someSpecificType) {
 // skip a test or raise an exception
 }

Resource objects, however:

- Return `false` for `is_resource()` checks.
- Raise a warning for `get_resource_type()` checks, and/or report the
resource object class name — which differs from the previous resource names
in all cases.


Would it be helpful if is_resource() raises an error if a resource 
object is provided as argument instead of returning false? (Should that 
be limited to the newly introduced resource objects in 8.1? Would a 
deprecation be enough?)


Of course, existing code would not work with that change. But you should 
be able to spot the error and fix it.


It should be possible to write code that works with PHP < 8.1 and >= 
8.1. Combined with Rowans idea of a Resource base class or interface 
that might even be easier?


(I assume it's of no additional help to change get_resource_type() to 
accept resource objects and return the same result as the former, 
corresponding resource type.)


Regards
Thomas

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

Re: [PHP-DEV] [RFC] is_literal

[Thomas Nunninger]

Hi!


class UserPreferences {
 private DB $db;

 function getColor(): string {
 $preferredColor = $this->db->getColor();

 if ($preferredColor === 'light') {
 return '#fff';
 }

 if ($preferredColor === 'dark') {
 return '#000';
 }
 return $preferredColor; // user has set custom color.
 }
}

Assume that both UserPreferences and getInfoPanel code is covered by
unit tests. The developer who made that change would run the tests,
see the tests pass and then push their code live. At which point, it
would cause an error in production, as the string returned would not
pass the is_literal check.

This would be a complete pain in the butt to fix.


When you write about testing in this database scenario, I find some 
additional issue: When you try to create pure unit tests you would 
somehow mock/stubb or replace the database with some test double. In 
that situation your tests will still pass even if testing the variant 
that the value comes from the database. Only some (infrastructure or 
end-to-end) test that covers the business logic plus the corresponding 
infrastructure by accident would uncover an error.


I wonder if we would need some method to mark a value/variable as 
non-literal. Or perhaps mark some return value (or input parameters?) in 
an interface/class as non-literal using some annotation?


That still puts the burden on the developer to think about that issue. 
But it's probably better than nothing.


Perhaps someone has a better idea?

Cheers
Thomas

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

Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals

[Thomas Nunninger]

Am 28.12.20 um 21:23 schrieb Larry Garfield:

There's been a number of discussions of late around property visibility and how 
to make objects more immutable.  Since it seems to have been well-received in 
the past, I decided to do a complete analysis and context of the various things 
that have been floated about recently.

The full writeup is here:

https://peakd.com/hive-168588/@crell/object-properties-and-immutability

I hope it proves stimulating, at least of discussion and not naps.


A really nice writeup and interesting to read.

But I have a question:


We then end up with the following combinations:

* public read, private write
* public read, private read, init write
* public none, private write
* public none, private read
* public none, private read, init write


What is the difference between

 (a) "public none, private read" and
 (b) "public none, private read, init"

write"? When will (a) be initialized?

And if there is really a useful case for (a) why is there no "public 
read, private read"?


Regards

Thomas

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

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

[Thomas Nunninger]

Hi,

Am 15.06.20 um 21:14 schrieb Stanislav Malyshev:

Hi!


I was surprised by the many negative responses: Partly just discussing
the term "blacklist" that is perhaps not the main issue. Or telling
people how they should feel and understand words.


Nobody tells you how to feel. But when you claim your supposed feelings
are the reason to censor other's speech then others have the right to
object. I am not sure why this surprises you.


I think the same applies to this topic


OK, so far for the 25 years of PHP existence I have never heard of a
person who was personally hurt by the use of term "blacklist". I've
heard lots of things said about PHP, good or bad, but today is the first
time I hear about this. So I am not sure we understand the term
"listening" in the same way.


It might be that discussions in the US are much more heated and 
fundamental than in Germany. And of course there is a political/social 
context to those discussions that I do not know - and that probably is 
not relevant for this list. And it might be that I misunderstood some 
nuances in some mails of this topic as I'm not an English native speaker.


But I'm not sure if I made my points clear:

* Personally, I have no issue with the term blacklist. (And it sounds 
really strange to me if someone wants to forbid the term black 
unconditionally. So: I do *not* propose to blindly follow the newest 
trend of political correctness without any reason.)


* I want to listen to others *who are affected*. (I assume most 
responses where written by white guys.)


* From my point of view it's not about censorship but about 
understanding - and about learning. Then I can make an informed decision 
how I want to behave in the future, how I want to balance my side with 
the side of someone else. (Just talking about censorship feels like 
trying to stop discussion. - I assume you did not intend that.)


* I didn't ask for opinions from people who are not offended. (Please, I 
do not want to censor you. But we heard a lot from that side.) I asked 
for concrete examples where people where offended in the context of the 
PHP project to get an understanding of the issue. If there is no 
response perhaps we can assume there is no issue? (At least for people 
on the list? Perhaps for people working in the IT context?)


Regards

Thomas

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

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

[Thomas Nunninger]

Hi,

I was surprised by the many negative responses: Partly just discussing 
the term "blacklist" that is perhaps not the main issue. Or telling 
people how they should feel and understand words.


Personally, I don't have any issues with "blacklist" - as I do not see 
any historical reason for that term and I don't know about current abuse 
of that term to discriminate against special groups. (I'm not a native 
English speaker - so perhaps I'm missing anything.) But if "master" is 
used in the context of "master / slave", I clearly understand that 
people feel offended (while I am completely fine if "master" is used in 
some other context).



Before discussing technical aspects about what changes would be required 
and what are the consequences, I'd like to point out some other aspect:


I'm a white guy. I can't tell women how they should feel about male 
wordings, statements, behavior, whatever; I just need to listen and try 
to behave in a way that they feel safe. (And of course there are aspects 
I can't change.)


I think the same applies to this topic, and it's important to get a 
common understanding of the problem space. (Let's talk about the 
solution space afterwards.)



Because of that, here are my questions:

* Are there any colored people on this list?

* What are your feelings about this topic regarding the PHP project and 
community?


* By what did you feel offended in the context of the PHP project 
currently or in the past?


* What would you need to feel safe and welcome? (Not restricted to 
technical changes.)


If you do not want to respond to the list directly, you can send the 
mail to me and I'll copy/paste the text of your response to the list 
anonymously.


(I'm not sure if we need to raise this questions in a broader context 
regarding other groups of people. I don't want to open a can of worms. 
But I don't want to forget about other groups.)


Regards
Thomas

Am 15.06.20 um 17:43 schrieb Daniel Rodrigues Lima:

Hi internals,

I think the time has come for the PHP internals to discuss the use of 
master/slave and blacklist terminologies.
As everyone can see, we are going through times of change in the world, see 
#blackLivesMatter for example.
Therefore, I propose that we discuss the non-use of terms master/slave, because 
the use of this can allude to the slavery and negative feelings about black 
people.

Some projects that changed the terminology:

* 
https://github.com/sebastianbergmann/phpunit/commit/8e9c76d33dab4095c9066072076f368193e4166d
* https://go-review.googlesource.com/c/go/+/236857/
* https://issues.apache.org/jira/browse/COUCHDB-2248
* https://bugs.python.org/issue34605

Greets,

Daniel Rodrigues.

geek...@php.net
https://twitter.com/geekcom2
https://www.linkedin.com/in/danielrodrigueslima/




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

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Thomas Nunninger]

Hi,

Am 12.08.19 um 10:26 schrieb Nikita Popov:

On Mon, Aug 12, 2019 at 10:17 AM Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:


Le lun. 11 déc. 2017 à 14:44, Nikita Popov  a
écrit :


Some time ago I introduced the following proposal for namespace-scoped
declares:

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

The idea is to allow specifying declare directives for a whole library or
project using:

 namespace_declare('Vendor\Lib', ['strict_types' => 1]);

I've finally gotten around to implementing this proposal (
https://github.com/php/php-src/pull/2972) and would like to move forward
with it.

The reason why I'm picking it up again is some feedback I received for the
explicit call-time send-by-ref proposal. The main objection seems to be
that the feature has limited usefulness if it's optional rather than
required, because you still can't be sure that something is a by-value
pass, just because no & is present. At the same time, we can't make this
required anytime soon due to the large BC impact.

Namespace-scoped declares are perfectly suited to resolve this problem. We
can introduce a require_explicit_send_by_ref declare directive to make the
call-site annotation required, and libraries/projects can easily opt-in to
it using namespace_declare(). There would be no BC impact, while at the
same time projects could benefit from the additional clarity and
performance improvements immediately.



I've read discussions about the notion of a "package" and the way we
should define its boundaries.
What about the following?

Individual files could declare their package using this style:


FTR I've created a draft-implementation for a package system here:
https://github.com/php/php-src/pull/4490

It uses a slightly different approach in that it keeps the package name a
string (that should usually match the Composer package name) and uses a
function to register the package.

The main annoyance is that this requires declaring the package in every
file, something I would like to avoid. An alternative I played with is to
allow specifying the package at include time, which would allow the
autoloader to specify which package a file is part. However, while this is
more ergonomic for the user, I'm afraid that this will make static analysis
& IDE scenarios problematic, because they will not be able to easily know
what the package is in cases that fall outside convention. So in the end,
an explicit per-file package declaration may be the best we can do.



I'm not sure if this was discussed/proposed before:

Why not have a concept similar to autoloaders that resolves a given 
class name to some declare statements.


That way you could implement a composer based resolver that takes a 
class name, (internally) resolves it to a package (based on the 
autoloader configuration in composer.json), and returns an array of the 
specified declare statements.


Developers do not need to specify a package or any declare statements in 
PHP files at all, as PHP (or static analyzers) would be able to ask the 
class-name-to-declare-statements resolver which declare statements a PHP 
file defines.


Alternatively, you could introduce the concept of a 
Package(Specification) class as proposed by Nicolas (but without the 
need to extend and implement it in each package). That way the resolver 
does not return the array of declare statements but an instance of the 
Package(Specification) class that was constructed by the composer-based 
resolver dynamically with the declare statements as defined in 
composer.json.


Not sure: Perhaps you even do not need a new concept of a resolver but 
could extend the concept of autoloaders?


Regards
Thomas

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

Re: [PHP-DEV] New website for the PHP project

[Thomas Nunninger]

Hi Thomas,

I regularly go to the php.net homepage for the live documentation search 
function just to make sure I'm using functions correctly.  My most 
frequent search is the date() function for the % code list.  One of 
these days I'll print out that docs page instead of looking it up every 
time to save everyone the bandwidth.  Of the things I'd miss the most 
would be the live documentation search feature to jump directly to what 
I'm looking for.  Google Search doesn't cut it here.


Try http://php.net/date

As long as you know the exact spelling of the method, that works 
perfectly. If you do not know exact spelling, perhaps you get some 
usable suggestions - more often not...


Regards

Thomas

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

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

[Thomas Nunninger]

Hi,

On 12/02/2016 02:54 PM, Matteo Beccati wrote:

On 02/12/2016 08:36, Thomas Nunninger wrote:

Hi,


So, if I only want to get the emulated prepared statement, I have to do
ob_start()/ob_get_clean(), then use a regexp to fetch it ? I want v1
back T_T


I second that. Why do you print it directly? Wouldn't it be better to
return a structured array with the information needed? If needed, you
can var_dump() the array yourself.


Could you please explain what's the use case? As far as I'm concerned
such information would only be useful during PDO driver development,
phpt files and bug reporting / fixing.


Sometimes I'd like to log what SQL is really used that I can 
analyze/modify a query without the need to replace all bound parameters 
manually before applying it to the command line of my database.


Additionally, it's a matter of good style in my opinion. E.g. if you 
return an array you can extend the structure later. If some test checks 
a string output you have to change this. If it checks the values of some 
array keys, the test is stable as long as you just add new keys.


Regards
Thomas

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

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

[Thomas Nunninger]

Hi,


So, if I only want to get the emulated prepared statement, I have to do
ob_start()/ob_get_clean(), then use a regexp to fetch it ? I want v1
back T_T


I second that. Why do you print it directly? Wouldn't it be better to 
return a structured array with the information needed? If needed, you 
can var_dump() the array yourself.


Regards
Thomas

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

Re: [PHP-DEV] Feature Request: inline pseudo-instruction

[Thomas Nunninger]

Hi,

On 10/04/2016 01:33 PM, Pascal KISSIAN wrote:

Hi everybody,





I have an application where a small file is included at multiple places.

So far so good.



The problem is that this include consists in a small piece of code which is
inside a multi-level loop.

The include is done about an average of 100.000 times .



When I manually replace the include with the code which is inside, the
performance boost is about  a 50-100 factor..
(with opcache enabled, it is far worst without opcache).


Despite the fact that your code really seems to be of bad quality as 
others mentioned: Did you configure your opcache not to check the file 
system each time if the file changed in the meantime?


Regards

Thomas


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

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Thomas Nunninger]

Hi,

On 09/06/2016 09:14 AM, Sebastian Bergmann wrote:

Am 05.09.2016 um 12:13 schrieb Derick Rethans:

You can't really ship PHP without a way to install extensions though!


Why not?

IMHO, PHP should not be shipped with any tool for installing PHP
components (PEAR Installer, Composer, ...) or extensions (PECL Installer,
...).

In my experience, people either install PHP using the package manager of
their OS distribution or they build PHP from the sources themselves. In
the latter case, they know how to build/install extensions manually and do
not need a tool for that.


Not in my case. In a few cases I needed to install extensions that were 
not provided by my package manager.


Regards

Thomas

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

Re: [PHP-DEV] [RFC Discussion] array_change_keys()

[Thomas Nunninger]

Hello,

shouldn't it be possible to return null as new key? That way you say: 
Use the next free integer index.


Not sure if returning null is wanted (as it could hide errors in the 
callback) or needed in some real world use cases. But it would be more 
in sync with $a[] = ...


Regards

Thomas

On 05/29/2016 03:13 PM, Colin O'Dell wrote:

Hello everyone,

I'd like to introduce a new RFC for your consideration and discussion:
https://wiki.php.net/rfc/array_change_keys  This would add a new function
named array_change_keys() which simplifies the process of re-keying an
array.

PHP currently has an array_change_key_case() method, but this only allows
keys to be changed to upper- or lower-case; no method exists to change the
keys to some custom user-defined value.  Although it's absolutely possible
to accomplish this without a special function, the alternate approaches
have several drawbacks:

  - Slower execution time compared to the proposed implementation.
  - Multiple lines and/or function calls are required.
  - Harder to understand the code's purpose with a quick glance.
  - The result of a "foreach" approach cannot be passed into another
function without using an intermediate variable.

A working implementation has been included with the RFC (huge thanks to
Jeremy Mikola for the heavy lifting here!)  I've also requested this patch
be added to 3v4l.org; I'll notify everyone if/when that happens.

I'd greatly appreciate if you could review this RFC and let me know your
thoughts.  I'd be happy to answer any questions you might have.

Regards,

Colin O'Dell



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

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[Thomas Nunninger]

Hi Andrea,

On 01/14/2015 11:20 AM, Andrea Faulds wrote:

Hi Thomas,


On 14 Jan 2015, at 10:08, Thomas Nunninger  wrote:


$i = 1;
$a = myFunc( $i );

declare(strict_typehints=TRUE);

function myFunc( float $f )
{
return otherFunc( $f );
}

function otherFunc( float $f )
{
...
}


As author of strict code I need to replace

return otherFunc( $f );

by

return otherFunc( (float) $f );


I'm not sure

- if this is what a strict coder wants and

- if you find an acceptable way to test your strict code if it works with 
non-strict code.


I don’t understand, I’m sorry.

If you are using declare(strict_typehints=TRUE); then all calls in a file are 
“strict”. If you are not, all calls in a file are “weak”.



Sorry, if my mail was not clear. My point was: If I write a library in 
strict mode and someone else is using it from his non-strict mode, he 
can pass an integer to myFunc() without an error. If I use this integer 
in my library and hand it over to otherFunc() (in my library) this will 
fail as integer is not accepted for float.


Or did I misunderstood the RFC and there is a casting of the integer to 
a float when calling myFunc()?


Regards

Thomas




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

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[Thomas Nunninger]

Hi,

On 01/14/2015 10:32 AM, Andrea Faulds wrote:

Hi Leigh,


On 14 Jan 2015, at 09:17, Leigh  wrote:

I really don't like this behaviour being changed at the call site. If
I design a function that I _know_ should only take a string, then I
want it to be an error if the user supplies anything else, so that
they know they messed up.


I don’t like the idea of being forced to use strict (or weak) type checking 
because the API author decided as much.


What happens with that code:


$i = 1;
$a = myFunc( $i );

declare(strict_typehints=TRUE);

function myFunc( float $f )
{
return otherFunc( $f );
}

function otherFunc( float $f )
{
...
}


As author of strict code I need to replace

return otherFunc( $f );

by

return otherFunc( (float) $f );


I'm not sure

- if this is what a strict coder wants and

- if you find an acceptable way to test your strict code if it works 
with non-strict code.



Regards

Thomas

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

Re: [PHP-DEV] Let's make a 5.7 release

[Thomas Nunninger]

On 08/16/2014 12:52 AM, Pierre Joye wrote:

On Sat, Aug 16, 2014 at 12:49 AM, David Soria Parra  wrote:

On 2014-08-15, Pierre Joye  wrote:



Let me summerize a few things that have come up:

  (1) phpng doesn't justify PHP7
  It does. It's a complete new engine. It has performance improvements. Where
  do you draw the line of what justifies a PHP 7? It's a major BC break and we
  needd a major version for it



No it does not. Even if it would do, that's not something I can live
with in the next 10 years. As I repeatedly said, with explanations
why.


Just a heretical question from someone who has no clue about PHP core:

What speaks against having PHP 8 one or two years after PHP 7?


I like the idea of

- having PHP 5.7 introducing deprecation warnings without additional 
features (and perhaps some cleanings regarding the spec?)


- full concentration on PHP 7 regarding phpng (including AST & co) and 
cleanings according to the spec.


- PHP 8 with other improvements that are currently planed for PHP 7. 
(Perhaps it's even possible to introduce most deprecation warnings of 
planned changes for 8 in 7 and 5.7.)



Regarding adoption: Agile teams/projects are able to follow the path 
from 5.6 to 5.7 (if needed) up to 7 and 8. Slow teams/projects can 
migrate from 5.6 to 5.7 "easily" and later to 8. Adoption to PHP 7 would 
not be a KPI of the PHP project.


Regarding branch maintenance: Support for 5.7 could be extended and for 
7 could be shortened if announced early enough (latest at GA of 7.0).


Regarding PHP project's project management: That would be release early, 
release often. Of course, extensions need to be changed twice for PHP 7 
and 8 - but the amount of changes should be almost the same.


A side note regarding the spec: I would not waste time to write/discuss 
a formal spec that describes all oddities of 5.6/7 or force 5.6/7 to 
follow a spec too much. The perspective of the spec is PHP 7 that is the 
first version where compliance to the spec is needed. (Probably Facebook 
has other plans. But I think one year to get it right on both sides - 
the spec and the implementation - is totally ok.)


Regards

Thomas

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

[Thomas Nunninger]

Hi Dan,

On 07/17/2014 02:12 PM, Dan Ackroyd wrote:

Thomas Nunninger wrote:

- "scalar parameter casting" should just be a convenience for coding:

  function foo( (int) $i, (string) $s )
  {
  }

is the same as:

  function foo( $i, $s )
  {
$i = (int) $i;
$s = (string) $s;
  }

or perhaps better::

  $i = (int) $i;
  $s = (string) $s;

  foo( $i, $s );


That way you decide if you want to be very strict about the data in your
variables or not, and both parties (strict vs. non-strict) can share code:


I agree generally with your mail apart from this bit - people don't
always just call code directly and so can't tell what types parameters
should be.

When you're calling code dynamically, e.g. through a dependency
injection container, you need to be able to inspect what types are
expected from outside the function.

e.g.

$dic->execute(
 'foo',
 [
 'i' => $request->getParam('i'),
 's' => $request->getParam('s')
 ]
);

Without having the type-hinting/casting information available in the
function, it's not possible for the calling code to know what type the
function is expecting, and so it isn't able to cast it to what the
function is expecting.


Perhaps I miss your point. But what is the difference to current 
behavior if you do not know about the types?


With casting the calling code does not need to know how to cast as the 
called code accepts the parameter if the value can be used without data 
loss. (If the example was misleading because the cast is happening 
before calling the function: This should only stress, that providing 
usable data is not a responsibility of the called function but the 
calling code.)


If the called function is strict it checks the input parameters in the 
function and raises some kind of error if information is lost on casting 
(not if the type is wrong). If information is lost, E_CAST is raised and 
PHP would use type juggling with expected or unexpected result (e.g. 
non-numeric strings casted to int). The difference to current behavior 
is that the product owner can decide if he wants strict behavior or not.



Or is your point about inspection of parameter type? Why shouldn't 
reflection be able to provide information about scalar parameter casting?


Regards

Thomas


On 17 July 2014 10:22, Thomas Nunninger  wrote:

Hi,

On 07/16/2014 10:45 PM, Andrea Faulds wrote:



On 16 Jul 2014, at 21:43, Zeev Suraski  wrote:


anything this RFC permits will
be permitted by zpp, it's the reverse that isn't necessarily true.



Right, so it needs to be fixed.  It makes no sense to force a new agenda
on the language that's inconsistent with the rest of the language.  Align
your new feature to the rest of the language, not the other way around.



But to do so would be to make the feature less useful, nor satisfy people
who want stricter hinting.



tl;dr:

- I'd like to have E_CAST on all castings/type jugglings even if we do not
get scalar type hinting.

- I propose to say/implement "scalar parameter casting" instead of "scalar
type hinting" with a casting syntax:

 function foo( (int) $i, ...)

That way we lower expectations, explain the different syntax/semantics in
contrast to hints, give a hint what scalar parameter casting does, and I see
the use-cases of both parties fulfilled.

---

I didn't follow the complete thread in detail. And I have to confess that
I'm a big fan of strictly "defining types of parameters", because I see how
it could help me in my work.

BUT: As I see it, E_CAST (with the existing type juggling rules/casts) plus
"scalar parameter casting" is the best compromise in the spirit/history of
PHP without BC breaks and I think all use-cases are satisfied:


- E_CAST notifies me about data loss on type juggling.

- "scalar parameter casting" should just be a convenience for coding:

 function foo( (int) $i, (string) $s )
 {
 }

   is the same as:

 function foo( $i, $s )
 {
   $i = (int) $i;
   $s = (string) $s;
 }

   or perhaps better::

 $i = (int) $i;
 $s = (string) $s;

 foo( $i, $s );


That way you decide if you want to be very strict about the data in your
variables or not, and both parties (strict vs. non-strict) can share code:


- With E_CAST you get additional information on data loss on type juggling
and casting in your complete code base. That's a plus for everybody who's a
little bit scary about type juggling in those cases.

- As a fan of strict mode I can develop my applications and libraries in
E_CAST mode via an error handler that throws exceptions on E_CAST. (We even
run our code with E_ALL in production to find edge cases.)

- I see the severity of E_CAST on a level like E_NOTICE and E_STRICT: Best
practice 

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

[Thomas Nunninger]

Hi,

On 07/16/2014 10:45 PM, Andrea Faulds wrote:


On 16 Jul 2014, at 21:43, Zeev Suraski  wrote:


anything this RFC permits will
be permitted by zpp, it's the reverse that isn't necessarily true.


Right, so it needs to be fixed.  It makes no sense to force a new agenda
on the language that's inconsistent with the rest of the language.  Align
your new feature to the rest of the language, not the other way around.


But to do so would be to make the feature less useful, nor satisfy people who 
want stricter hinting.


tl;dr:

- I'd like to have E_CAST on all castings/type jugglings even if we do 
not get scalar type hinting.


- I propose to say/implement "scalar parameter casting" instead of 
"scalar type hinting" with a casting syntax:


function foo( (int) $i, ...)

That way we lower expectations, explain the different syntax/semantics 
in contrast to hints, give a hint what scalar parameter casting does, 
and I see the use-cases of both parties fulfilled.


---

I didn't follow the complete thread in detail. And I have to confess 
that I'm a big fan of strictly "defining types of parameters", because I 
see how it could help me in my work.


BUT: As I see it, E_CAST (with the existing type juggling rules/casts) 
plus "scalar parameter casting" is the best compromise in the 
spirit/history of PHP without BC breaks and I think all use-cases are 
satisfied:



- E_CAST notifies me about data loss on type juggling.

- "scalar parameter casting" should just be a convenience for coding:

function foo( (int) $i, (string) $s )
{
}

  is the same as:

function foo( $i, $s )
{
  $i = (int) $i;
  $s = (string) $s;
}

  or perhaps better::

$i = (int) $i;
$s = (string) $s;

foo( $i, $s );


That way you decide if you want to be very strict about the data in your 
variables or not, and both parties (strict vs. non-strict) can share code:



- With E_CAST you get additional information on data loss on type 
juggling and casting in your complete code base. That's a plus for 
everybody who's a little bit scary about type juggling in those cases.


- As a fan of strict mode I can develop my applications and libraries in 
E_CAST mode via an error handler that throws exceptions on E_CAST. (We 
even run our code with E_ALL in production to find edge cases.)


- I see the severity of E_CAST on a level like E_NOTICE and E_STRICT: 
Best practice - if others do not understand/care it's their "problem" 
but they can use my code like each other code.


- As a fan of non-strict behavior, you can provide a string for a 
parameter that is defined to be an integer. If it contains a number you 
are happy that my code works as PHP deals with casting. If your string 
does not contain a usable value you have to live with the good old PHP 
way when you use code with wrong input data and my code treats it as an 
integer and you perhaps have some data loss. But that's not the 
responsibility of my code - especially if I interpret the casting syntax 
as casting the parameters before hitting my method/function. (BTW: I 
don't think that casting should be used as sanitizing of user input like 
it was proposed/said to be widely used. I prefer validation over 
sanitizing.)


- Depending where and how I define my error handler, I do not see that 
my code needs to behave differently if E_CAST is enabled or not. I think 
you should implement your error_handler for E_CAST in the spirit of 
Symfony's debug mode: In debug mode all errors are converted to 
exceptions but they are ignored in production mode. I guess you'd never 
say: My application behaves differently. Otherwise you probably use 
exceptions for control flow. (I do not say that you have to disable 
E_CAST for your production mode. But if your code passes all tests in 
E_CAST, there is a good chance that it works without E_CAST as well. 
Then it's your decision as product owner if you have to break on errors 
in edge cases or not.)


- Regarding consistency to array and object hints: Using the casting 
syntax/semantics you could even provide (array) and (object) as "scalar 
parameter casting" in contrast to the hints. But of course you can argue 
that users are confused about "(array)" vs. "array". I could live with 
that confusion as people have to learn about "parameter casting" and 
that should be explicitly mentioned in the docs/tutorials/blog posts/...


- I don't know if there is a downside for static code analysis. But 
probably you even need defined return types for that.



Regards

Thomas

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

Re: [PHP-DEV] 6.0 And Moving Forward

[Thomas Nunninger]

Hi,

On 07/17/2012 05:40 AM, Nicholas Curtis wrote:
> Great Idea, would love to see current standard library in a legacy
> namespace and a new standard library implemented as methods of
> primitive types.

The idea to separate old and new behaviour has some charm.

> $string = "Hello, World";
> echo $strong->toUpper(); // HELLO, WORLD
>
> $int = 3;
> echo $int->round(2); // 3.0
>
> While still preserving $legacy.strTopUpper($string) and 
$legacy.round($int)


I wouldn't do that because it implies two things:

- you have to change existing code (if I understand your syntax
  correctly)

- you could mix old and new style in one file


Somebody proposed (in some other thread some weeks ago) to introduce 
some code versioning. IIRC he proposed the "of "naming thing. And of course: You could still mix different styles in one 
file - but not in one php block. And that's easier to handle by coding 
conventions in the team.)


Versioning could be a chance to evolve the language and not to mess with 
existing code. BUT: I don't know if that's doable internally. And it's 
probably a lot of work...


Regards
Thomas


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

Re: [PHP-DEV] [VOTE] DateTime and Daylight Saving Time Transitions

[Thomas Nunninger]

Hi,

sorry for late comment.

You write: "The ST or DST modifiers can only be used when specifying times 
during the backward transition period. Using the modifiers at other times 
will throw an exception in object-oriented style code while procedural style 
code will return false without triggering errors."

In my opinion this makes code more difficult as I need to check if the time is 
in the transition time. In my opinion it should be ok to add (D)ST all the 
time when it is (D)ST - and I don't see that it should be wrong (but I don't 
know enough about standard formats). Just ignore it internally if you don't 
need that information.

Thomas


Am Dienstag, 25. Oktober 2011 17:06:38 schrieb Daniel Convissor:
> Hi Folks:
>
> Please take a moment to review the DateTime transitions RFC and vote on
> it.  I encourage voting on it to ensure we are all on the same page as
> to how PHP will handle transitions.  Voting is open through 10/31.
>
> Read: https://wiki.php.net/rfc/datetime_and_daylight_saving_time
> Vote: https://wiki.php.net/rfc/datetime_and_daylight_saving_time/vote
>
> Thanks,
>
> --Dan
>
> --
>  T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
> data intensive web and database programming
> http://www.AnalysisAndSolutions.com/
>  4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409

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

Re: [PHP-DEV] Type hinting

[Thomas Nunninger]

Hi,

if it comes to auto-converting (that's different from existing type-juggling): 
wouldn't it be nice, to change type-juggling as well?

I know about BC breaks here, thus it would need till PHP 7 or so to become the 
default behavior. But I think, BC breaks mainly occur in the cases where 
type-juggling is more hiding programming errors than helping the user - that 
is: where the developer should really care about checking and/or casting.

As an advantage, hints and type-juggling would at least behave consistent, 
reducing complexity for the users (and perhaps internally for you as core 
developers as well).

Am Donnerstag, 27. Mai 2010 07:42:32 schrieb Zeev Suraski:
> Can anybody share with us *common* cases where strict typing would be
> necessary, and the proposed auto-converting type hints won't do?

If you use CouchDB as backend (where data is stored as JSON), there is a 
difference if you store "42" , 42, or 42.0. IIRC I read on the CouchDB 
mailing list that this can influence view sorting. (As I strictly care about 
types in my application, I didn't had problems yet.)

Thomas

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

Re: [PHP-DEV] Type hinting

[Thomas Nunninger]

Hi,

another end-user perspective:

Am Montag, 24. Mai 2010 14:12:41 schrieb Zeev Suraski:
> At 14:48 24/05/2010, s...@geleia.net wrote:
> >Adding strict typing would be the largest
> >
> > > inconsistency in PHP's core syntax, ever.
> >
> >I disagree. The === operator already checks the type of the variables.
>
> We can agree to disagree regarding the level of understanding the
> average PHP developer has about zval.type - but it doesn't change my
> opinion that strict type checking would be the biggest inconsistency
> in PHP's core syntax ever.  These two assertions are independent from
> each other.

I don't know if I have a full understanding about zval.type on internal 
C-level. But in my code I always use strict type checking in comparisons and 
in functions like in_array that offer that possibility. That's because I 
learned the hard way how much debugging time it saves if I handle my variable 
types with care. (Things like '1' == '2' 
evaluating to true on 32 bit don't make it better.)

I'd say: the type-juggling is not the *big plus* of PHP. BTW: if I read 
some "PHP is so enterprise-ready" articles, I never read about the advantages 
of weak types. (I'd even liked it, if there would be an optional(!) 
possibility of variable type declaration. Who cares, could use it - others 
ignore it.)

In contrast to "normal" PHP behavior where the user doesn't care about 
variable types, with type hinting in methods/functions it is explicit what's 
required. Every non-strict type handling is contra-productive. So if someone 
wants to use my function with hints, he needs to care about his types.

My opinion:

- Don't introduce another kind of type juggling related to type hinting - 
that's making it worse because many users won't know/see/understand the 
differences.

- If it's not strict, I don't see a real advantage of type hinting (besides 
static code analysis and no need to declare types in doc blocks).

- If you want to support weak type hints, declare strict and weak hints. 
Because I like strict type checks. And I don't see, why I shouldn't be able 
to have strict checks but others that do not care about their types should 
have something that looks like type hinting. (I guess, they won't use it 
anyway if they don't care about types.) PHP offers both ways of strict and 
weak handling with comparisons and some functions - so it should offer both 
ways here as well.

- If you don't want to distinguish beetween strict and weak hints, create some 
ini setting that influences the behavior. (I'm not a fan of that.)

- I see that there will be problems when a developer, who doesn't care about 
types, wants to use an external library with strict hinting. So perhaps the 
way to go is: provide strict and weak hinting plus an ini setting to reduce 
strict to weak hints if someone wants to include a "strict" library. (I guess 
the other way round - make weak hints to strict hints - is probably not so 
usefull, as I can't rely on a library with weak hinting to be 100% strict 
hinting compliant internally.)

I hope this post is not to offensive. Just wanted to make my point clear that 
I want to be able to use strict hinting, because I don't like the weak types 
regarding software quality. (No, I'm not using the wrong language.)

Regards,

Thomas

>
> >That said, I don't think strict type checking is the best option. I just
> >think it's better than inventing a new complex set of rules that are
> >inconsistent with everything else.
>
> Suggest we put aside the 'is strict typing better than variant X of
> auto-conversion or not' discussion since it's mostly academic.  I
> think we both agree that we need to find the best version of
> auto-conversion.
>
> >I think the best option is to align the type checking with
> >zend_parse_parameters (this is not the same as an implicit cast) and make
> >it stricter. This includes:
> >* disallow string to float/int when it contains non-numeric characters
> >(includes "123abc")
> >* disallow string/float to int when it causes overflow instead of the
> >current behavior (triple cast (long)(unsigned long)(long long)). "L" would
> >retain the current behavior.
> >
> >Although a depart from backwards compatibility, I doubt this would cause
> >much brekage.
>
> Sounds acceptable to me, that's along the lines of the 3rd option
> which appears to be getting the most traction.  I'd also no
> conversion of arrays to scalars to that list.
>
> Zeev

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