Re: [RFC] OOP API for cURL extension

> Sara Golemon hat am 14.02.2024 19:47 CET geschrieben: > > > Good afternoon folks, I'd like to open discussion on adding OOP APIs to the > cURL extension. > https://wiki.php.net/rfc/curl-oop > > This has been a long standing bug-bear of mine, and I think its time has come. > > try { > (new

Re: [PHP-DEV] PHP 8 Backward Incompatible Change Notifications

Hi Alan, regarding "String to Number Comparison", you can cast the value to int to get the old behaviour: php -r "var_dump(0 == (int) '0');" php -r "var_dump(0 == (int) '0.0');" php -r "var_dump(0 == (int) 'foo');" php -r "var_dump(0 == (int) '');" php -r "var_dump(42 == (int) ' 42');" php -r

Re: [PHP-DEV] Future stability of PHP?

I fully understand your point, having more tests is the best thing to do. Unfortunately many old code bases are not written to be tested easily. There is excessive inheritence, traits, reflection, globals, static calls, missing DI, magic functions, feature flags, database dependancies (e.g. 1

Re: [PHP-DEV] Future stability of PHP?

> Tim Düsterhus hat am 10.04.2023 16:48 CEST geschrieben: > > > Hi > > On 4/10/23 16:37, Thomas Bley wrote: > > Regarding compatibility promise, I'd also like to mention that things are > > quite complex now, e.g. > > > > https://3v4l.org/VfAr

Re: [PHP-DEV] Future stability of PHP?

Regarding compatibility promise, I'd also like to mention that things are quite complex now, e.g. https://3v4l.org/VfAr4 has 4 different outputs between php 7.x and 8.x. From userland perspective, having Craig Francis hat am 10.04.2023 14:58 CEST > geschrieben: > > > On 9 Apr 2023, at

[PHP-DEV] Discussion array_get_type()

Hello, since there are currently no type declarations for specific arrays (int[], string[], MyClass[], etc.), I'd like to ask if it would make sense to have a function array_get_type() in php core? As I'm not a C developer, I can only ask for your help for the implementation. I think having it

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

Hello, I'd also like to propose to use null: [null, null, $username] = getUserData(); foreach ($source as $key => null) {} Regards Thomas > David Rodrigues hat am 02.09.2020 16:24 geschrieben: > > > I think "void" is a good solution and is very clear, compared to "_". > > [void, void,

Re: [PHP-DEV] [RFC] Named arguments

> Marco Pivetta hat am 5. Mai 2020 um 16:11 geschrieben: > > Hey Nikita, > On Tue, May 5, 2020 at 3:51 PM Nikita Popov wrote: > > Hi internals,> I've recently started a thread on resurrecting the named > > arguments proposal(https://externals.io/message/109549), as this has come > > up

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

ur punishes > future users of PHP for our past mistakes. > > On Aug 28, 2019, at 12:05 PM, Thomas Bley wrote: > > > > Normally every code base has old and new code, some is actively maintained, > > some is probably third-party maintained, some is unmaintai

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

Normally every code base has old and new code, some is actively maintained, some is probably third-party maintained, some is unmaintained. Business normally not calculates costs for upgrading, securing, GDPRing old code, so bigger changes always leave some people behind. I would prefer to write

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

Hello, I understand that breaking changes always need extra work, but in this case I think it's a quick change. On my code base (mostly legacy with 1.8m lines), I ran this and got 10 matches to check: grep -rin " vsura...@gmail.com hat am 24. April 2019 um 15:41 geschrieben: > > > FWIW, > >

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

Nikita Popov wrote on 24.01.2019 15:40: > On Thu, Jan 24, 2019 at 3:08 PM Larry Garfield > wrote: > >> On Thu, Jan 24, 2019, at 8:02 AM, Nicolas Grekas wrote: >> > Thank you Nikita, >> > >> > the RFC looks solid to me. Using magic methods makes perfect sense to >> allow >> > a smooth migration

Re: [PHP-DEV] Proposal: change precision for output functions

Semen Dubina wrote on 07.01.2019 16:38: > Hi, everyone! > Original PR and description see: https://github.com/php/php-src/pull/3460. > > Because of the accuracy constraint set by the 'precision' variable, debugging > problems often occur, and many developers consider the limited accuracy to be

Re: [PHP-DEV] Strict switch statements

Nikita Popov wrote on 14.06.2018 10:35: > On Thu, Jun 14, 2018 at 6:53 AM, Sara Golemon wrote: > >> Just for casual discussion at this point: >> https://github.com/php/php-src/pull/3297 >> >> switch ($a) { >> case FOO: >> // Works exactly as current behavior. >> break; >> case

Re: [PHP-DEV] Fixing halfway implemented session management - timestamp based session management OR remove session_regenerate_id()

why not have a new session module? those who want no change for existing applications keep the old one, new projects can use the new one, those who want more security port their code to the new one. e.g. use session2_start(), etc. Regards Thomas Yasuo Ohgaki wrote on 25. Sept 2016 22:35: > Hi

Re: [PHP-DEV] [RFC][VOTE] New operator (short tag) for context-dependent escaping

> it's just that no one except you thinks this is a good solution it's just that no one - who is allowed to vote and wants to vote - thinks this is a good solution. Regards Thomas Rasmus Schultz wrote on 07.08.2016 13:06: > Looks like it's unanimously a No. > > Michael, don't be discouraged

Re: [PHP-DEV] Tracing exit()

Hi! having a complete trace from an exception would be great: function shutdown() { $e = new Exception(); echo $e->getTraceAsString(); } function test() { exit; } register_shutdown_function('shutdown'); test(); gives: #0 [internal function]: shutdown() #1 {main} Regards Thomas Bishop

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> This can be done with e.g. "". sometimes you also need to sanitize html, e.g. see http://htmlpurifier.org/ Regards Thomas Michael Vostrikov wrote on 30.07.2016 16:01: >> This new tag will not simply replace because you still need > to output HTML sometimes. > > This can be done with

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

wrote on 28.07.2016 10:29: > On 27 July 2016 23:45:10 GMT+01:00, Thomas Bley <ma...@thomasbley.de> wrote: >>> In many ways, defining a built-in function e($string, $context) would >> >>> fulfil most of the above. >> >>If things are so easy, why does so mu

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> In many ways, defining a built-in function e($string, $context) would > fulfil most of the above. If things are so easy, why does so much code exist with XSS problems? Regards Thomas Rowan Collins wrote on 27.07.2016 22:57: > On 26/07/2016 14:15, Michael Vostrikov wrote: >> Ok. Just ask

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

fix code that is using the frameworks in a wrong way. Regards Thomas Rowan Collins wrote on 24.07.2016 20:29: > On 24/07/2016 19:09, Thomas Bley wrote: >>> Then why is absolutely everything in the current RFC optional and >>> configurable to the Nth degree? >> It's one h

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

toload_register(), error_reporting(), etc., this concept is proven to work. > In my opinion, they are central to the feature, not an optional extra. maybe you can join the rfc and provide the implementation? Regards Thomas Rowan Collins wrote on 24.07.2016 19:41: > On 24/07/2016 18:06, Thomas

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

ards Thomas Christoph Becker wrote on 24.07.2016 18:52: > On 24.07.2016 at 18:21, Thomas Bley wrote: > >>> >>> >>> instead of >>> >>> >> >> benefits are using static code analyzers, grep " > Well, something like `gre

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

you have to do either way. the thing here is that people can use https://github.com/phpmyadmin/phpmyadmin.git git log | grep -i xss | wc -l 206 Regards Thomas Rowan Collins wrote on 24.07.2016 18:39: > On 24/07/2016 17:21, Thomas Bley wrote: >>> >>> >>> instead o

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

1742f2 Regards Thomas Thomas Bley wrote on 24.07.2016 18:21: >> >> >> instead of >> >> > > benefits are using static code analyzers, grep " Having function names with single characters is bad taste and only useful for > obfuscating. > Usin

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> > > instead of > > benefits are using static code analyzers, grep " On 24.07.2016 at 16:55, Thomas Bley wrote: > >> In total a good rfc everybody should be happy with. > > I'm not happy (to put it mildly) with the RFC as it's now. The RFC > spea

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> php already uses ?: for ternary operator, so users get a bit confused by using it for escaping. > this allows multiple interpretations: meaning $a context $b meaning $a | $b context 'html' > $b ?> |> may be used by Pipe Operator rfc, if vote is successful > if ($context == 'html') {

Re: [PHP-DEV] Pipe Operator v2

to me this code is perfectly readable and static code analysis is only complaining about missing semicolons at the end of the lines and short variable names: $x = loadConfig(); $x = buildDic($x); $x = getApp($x) $x = getRouter($x) $x = getDispatcher($x, $request) $x = dispatchBusinessLogic($x,

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> Hacking non FQN resolutions to inject another > escaper implementation as in "" was a > creative idea but it seems inconsistent with the preferable "PHP way" to > handle these edge cases. Just imagine use cases like: That way people can use the escaping operator in all kinds of templates

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

if I see it correctly, this is just a framework for defining callbacks to a escaping operator, without a implementation of "html" and "js"? Not sure if this helps. Regards Thomas Michael Vostrikov wrote on 16.07.2016 17:33: > Hello. > I have created RFC about context-dependent escaping

Re: [PHP-DEV] New escaped output operator

we should > improve the features we already have instead, which benefits the > language as a whole, not just templates. Improving on functions is > long over due... > > > On Thu, Jun 30, 2016 at 9:52 PM, Thomas Bley <ma...@thomasbley.de> wrote: >> I would pre

Re: [PHP-DEV] New escaped output operator

I would prefer to have ENT_HTML5 as the default flag included, since normally all new html code is html5. Maybe split voting between I've tried to gather all arguments for and against. > > To be clear. I suggest new operator like '' which is > equivalent of . > It is only for HTML context. Flag

Re: [PHP-DEV] New escaped output operator

Of course you can make the discussion endless by mentioning escaping of all kinds of third party frameworks like jQuery, but that's a bit off-topic here. As mentioned a few times in this thread, ... when I click reply :) Rowan Collins wrote on 21.06.2016 00:00: > On 20 June 2016 17:40:05

Re: [PHP-DEV] New escaped output operator

to make it more clear: is a shortcut for: Using 2016-06-20 11:12 GMT+02:00 Lester Caine : > >> On 20/06/16 07:00, Niklas Keller wrote: >> >> Now ... I want to add content that includes >> >> > it needs to be in the format >> >> > scriptalert(xss)script so that it never

Re: [PHP-DEV] New escaped output operator

you can never avoid people writing things incorrectly, just look at code using addslashes() instead of mysql_real_escape_string() ... Regards Thomas Walter Parker wrote on 20.06.2016 01:41: >> >> >> >> > where getting it 90% correct is worse that not doing anything at all. >> > Things like

Re: [PHP-DEV] New escaped output operator

I think it's best to create a rfc and put it to vote: https://wiki.php.net/rfc/howto Having Guys, wait please) I don't suggest escaping package for all contexts and > for all cases. This is not what I described in my first letter. My point is > that the main job of echo operator "" is output an

Re: [PHP-DEV] New escaped output operator

Sure you can implement that in userland, but people don't do it or make it too complicated, so you get every day code with unescaped stuff. Regards Thomas Ryan Pallas wrote on 18.06.2016 00:27: > > > On Fri, Jun 17, 2016 at 2:23 PM, Thomas Bley <ma...@thomasbley.de

Re: [PHP-DEV] New escaped output operator

re you actually reading and understanding what the others are > saying? > > You seem to be answering questions that have not been asked or giving the > simple, easy and wrong answer. > > > Walter > > On Fri, Jun 17, 2016 at 1:37 PM, Thomas Bley <ma...@thomasbley.de>

Re: [PHP-DEV] New escaped output operator

you can simply add the context to the current output operator: (=strip_tags) Regards Thomas Stanislav Malyshev wrote on 17.06.2016 22:14: > Hi! > >> Most of output code is an output of properties of database entities, and >> only in some cases it's needed to concatenate HTML into string

Re: [PHP-DEV] New escaped output operator

using the default encoding from php.ini's default_charset should be no problem, htmlspecialchars() already does it if the encoding parameter is not provided. Regards Thomas Niklas Keller wrote on 17.06.2016 22:31: > Hi, > > the issue is that things have to be escaped dependent on the context.

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi, what about having "strict classes"? A strict class would be like a database table, each property defined must have a type. Each property defined must be initialized before being accessed, or have a default value. e.g. strict class Foo { public int $id; public bool $enabled;

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

maybe you can add a few examples to the type table in the rfc, so everybody knows how it actually works: function test(int | float | string $a) {var_dump($a);} test(42.0); // float(42) test('42'); // string(2) "42" function test2(int $a) {var_dump($a);} test2(42.0); // int(42) test2('42'); //

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

chCodes = null, string $matchMessage = null): bool Then it would be clear that we can't match an array of messages. But as said before string | int | ... makes no sense to me. Regards Thomas Jordi Boggiano wrote on 03.06.2016 17:16: > On 03/06/2016 15:58, Thomas Bley wrote: >> To me type de

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

tr_replace) since we can cast the string easily to array and calling a string parameter with an array would give a fatal error. Regards Thomas Rowan Collins wrote on 03.06.2016 16:32: > On 03/06/2016 15:24, Thomas Bley wrote: >> maybe easier to get a majority from voters if defining

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

maybe easier to get a majority from voters if defining union types only in strict mode for 7.1? Regards Thomas Rowan Collins wrote on 03.06.2016 15:40: > On 03/06/2016 13:30, Bob Weinand wrote: >> >> The *weak casting* rules (i.e. what gets converted how and what can be >> converted to the

Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

why not try all types weakly from left to right in weak mode? Rule: if type check would give a fatal error for a type, try next type. E.g. function i(int | string $var) { echo gettype($var) . ' ' . $var; } i('10'); // int 10 i('10a'); // int 10 i('foo'); // string foo i(10.0); // int 10 i(10); //

Re: [PHP-DEV] [RFC][Vote] Typed Properties

7.0's dual-mode, scalar > type declaration of function arguments and boosting the confusion power. I > would want a new name for this complement-of-strict mode. "Weak" and > "liberal" don't quite do it. Promiscuous mode? ;) > > Tom > > > On 5/26/16, 10:40 AM, &q

Re: [PHP-DEV] [RFC][Vote] Typed Properties

var_dump(isset($a->w)); // false Regards Thomas Tom Worster wrote on 26.05.2016 15:53: > On 5/25/16 5:52 PM, Thomas Bley wrote: >> I'm not seeing a problem here: >> >> class A { >> public int $x; >> public ?int $y = null; >> public int $z = 42; >>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Of course isset() has a special behaviour. So having some kind of real_isset() or initialized() would be nice. Regards Thomas Thomas Bley wrote on 26.05.2016 00:38: >>> var_dump($a->z); // 0 + notice >> The notice should be 'variable does not exist' as at this point $a-&g

Re: [PHP-DEV] [RFC][Vote] Typed Properties

private $z = 42; public function __construct() { unset($this->z); } } $a = new test(); $a->z = 21; // fatal: Cannot access private property... So after unset, $a->z should still have context. Regards Thomas Lester Caine wrote on 26.05.2016 00:13: > On 25/

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Currently the rfc also checks the properties for being initialized. I think it's still faster than most userland implementations using __get() for type checks and parsing phpdoc for type information. Regards Thomas Stanislav Malyshev wrote on 25.05.2016 23:56: > Hi! > >> var_dump($a->w); //

Re: [PHP-DEV] [RFC][Vote] Typed Properties

gt;> $a = new A; >> var_dump($a->x); // 0 + notice >> var_dump($a->y); // null >> var_dump($a->z); // 42 >> unset($a->z); >> var_dump($a->z); // 0 + notice >> var_dump($a->u); // null + notice >> var_dump($a->v); // null + notice &g

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Following "Type safety is the goal of this RFC, not validating objects.", it would be better to do implicit casting for uninitialized properties (whenever implicit casting is possible) or use null for nullable types: class A { public int $x; public ?int $y = null; public int $z = 42;

Re: [PHP-DEV] [RFC] Pipe Operator

Hey, to me recursion and pipe operator looks really hard to read, I guess this is faster and better readable: foreach (scandir($arg) as $x) { if ($x == '.' || $x == '..') { continue; } $x = $arg . '/' . $x; // inline getFileArg ... $allFiles[] = $x; } Regards Thomas Bob Weinand

Re: [PHP-DEV] [RFC] PHP Attributes

the 7.1 one that has been processed through a script to remove > any <<>> syntax, or to transform it (if pre/post attributes instructions > were to be implemented in the core). > > Regards, > Ben. > > Le Sun, 24 Apr 2016 01:09:08 +0200, "Thomas Bley"

Re: [PHP-DEV] [RFC] Nullable Types

> Note that the same /would/ be possible with union types if given precedence: > > function fn(): int|false {} false is currently not supported in the union_types rfc. Regards Thomas Fleshgrinder wrote on 21.04.2016 21:33: > On 4/21/2016 6:33 PM, Thomas Bley wrote:

Re: [PHP-DEV] [RFC] Nullable Types

} Regards Thomas f...@thefsb.org wrote on 21.04.2016 15:05: > Hi Thomas, > > > What is a default return declaration? Is this for branches within the function > that do not lead to a return statement? > > > Tom > > > > > > From: Thomas Bley > Sen

Re: [PHP-DEV] [RFC] Nullable Types

What do you think about default return values? e.g. function foo(): db_result = null { } function canLogin(): bool = false { } Regards Thomas Dmitry Stogov wrote on 20.04.2016 18:13: > What we really miss now, is an ability to define nullable return types. > > >

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.1

Nikita Popov wrote on 18.02.2016 13:41: > Hi internals! > > I've created a bulk-deprecation RFC for PHP 7.1: > https://wiki.php.net/rfc/deprecations_php_7_1 > > I'm using this RFC to collect various deprecations targeting PHP 7.1, as > having individual RFCs for these is too much management

Re: AW: [PHP-DEV] [RFC] Allow specifying keys in list()

Hi Robert, for named parameters, I would prefer this syntax over list(): function foo($foo, [a: string $a, b: int &$b, c: bool $c = true]) { ... work with $foo, $a, $b, $c } $b = 42; foo('foo', ['a' => 'bar', 'b' => $b]); function bar($foo, SomeClass {a: string $a, b: int &$b, c: bool $c =

Re: [PHP-DEV] [RFC] Allow specifying keys in list()

What about using objects with list()? class Point { public function __construct($x, $y) { $this->x = $x; $this->y = $y; } } $point = new Point(21, 42); list('x' => $x, 'y' => $y) = $point; Regards Thomas Andrea Faulds wrote on 17.01.2016 03:32: > Hi everyone, > > Here's an RFC that would

Re: [PHP-DEV] [RFC] Arrow Functions

Pavel Kouřil wrote on 03.10.2015 10:06: > On Sat, Oct 3, 2015 at 1:17 AM, Levi Morrison wrote: >> I messaged the list about this feature before I had the RFC written up >> for it. The RFC[1] is slightly different from what I proposed in the >> previous thread, so please

Re: [PHP-DEV] Make strict mode more strict?

Yasuo Ohgaki wrote on 17.09.2015 00:10: > Hi all, > > PHP 7 has strict_types mode for function parameters/return values and > these are binded to certain type strictly. > https://wiki.php.net/rfc/scalar_type_hints_v5 > > Why not make strict_types mode more strict? > The idea is as follows: > >

Re: [PHP-DEV] [RFC] [Discuss] Random Functions Throwing Exceptions in PHP 7.0.0

Larry Garfield wrote on 23.08.2015 18:19: On 08/22/2015 07:33 PM, Thomas Bley wrote: Anthony Ferrara wrote on 22.08.2015 21:58: All, I am putting a simple RFC up for discussion to make random_* throw exceptions on failure in order to ensure we fail-closed. https://wiki.php.net/rfc

Re: [PHP-DEV] [RFC] [Discuss] Random Functions Throwing Exceptions in PHP 7.0.0

Scott Arciszewski wrote on 23.08.2015 02:50: On Sat, Aug 22, 2015 at 8:33 PM, Thomas Bley ma...@thomasbley.de wrote: Anthony Ferrara wrote on 22.08.2015 21:58: All, I am putting a simple RFC up for discussion to make random_* throw exceptions on failure in order to ensure we fail-closed

Re: [PHP-DEV] [RFC] [Discuss] Random Functions Throwing Exceptions in PHP 7.0.0

Niklas Keller wrote on 23.08.2015 16:30: why not have false + e_warning for strict_types=0 and fatal error for strict_types=1 ? Doing function random_int(): int { ... How's this connected to `strict_types`? It's not. If people use this function without reading documentation,

Re: [PHP-DEV] [RFC] [Discuss] Random Functions Throwing Exceptions in PHP 7.0.0

Nikita Nefedov wrote on 23.08.2015 18:27: On 23 Aug 2015, at 18:37, Thomas Bley ma...@thomasbley.de wrote: consider this code: declare(strict_types=0); ini_set('display_errors', '1'); function get_random_int(): int { return false; } echo get_random_int(); and then use

Re: [PHP-DEV] [RFC] [Discuss] Random Functions Throwing Exceptions in PHP 7.0.0

Anthony Ferrara wrote on 22.08.2015 21:58: All, I am putting a simple RFC up for discussion to make random_* throw exceptions on failure in order to ensure we fail-closed. https://wiki.php.net/rfc/random-function-exceptions Considering this topic has already been discussed, I intend to

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

Pierre Joye wrote on 28.07.2015 23:05: The On Jul 28, 2015 11:42 PM, Christoph Becker cmbecke...@gmx.de wrote: Rowan Collins wrote: On 28 July 2015 18:33:31 BST, Matt Tait matt.t...@gmail.com wrote: Hi all, I've written an RFC (and PoC) about automatic detection and blocking of SQL

Re: [PHP-DEV] PHP 7.0.0alpha1 Released for Testing!

Jefferson Gonzalez schrieb am 13. Juni 2015 21:04: On 06/12/2015 04:13 PM, Rasmus Lerdorf wrote: You can get even more speed by compiling with --enable-opcache-file and then in your php-cli.ini add: opcache.enable_cli=1 opcache.file_cache=/var/tmp opcache.file_cache_only=1

Re: [PHP-DEV] Voting irregularities

Which post says that we're turning PHP into Java I think there are people who want to switch from Java to PHP, maybe they feel easier with declare(strict...). Also in the past, some companies switched from PHP to Java because they wanted more strictness in their backend code. I don't like

Re: [PHP-DEV] [RFC] Basic Scalar Types

Bob Weinand wrote on 14.03.2015 00:07: Am 13.03.2015 um 23:03 schrieb Zeev Suraski z...@zend.com: Maybe I was naïve, but I thought I had a better way to make both weak strict camps happy, instead of just ignoring the strict camp altogether. While there was some opposition to it - it mostly

Re: [PHP-DEV] [RFC] Anonymous Classes

Just a question, can I do: $c = class { public static function square($i) { return $i*$i; } }); echo $c::square(42); or $c = class extends DateTime { public static function createFromFormat($translateFormat, $time) { $translateFormat = str_replace('foo', 'Y-m-d',

Re: [PHP-DEV][RFC][VOTE] Enable error_handler callback parameters to be passed by reference

Hi all, the rfc was declined: - Allow $errstr parameter to be passed by reference: 3 - Allow $errno, $errstr, $errfile, $fileno parameter to be passed by reference: 1 - No, Allow none of the parameter be a reference parameter: 16 Regards Thomas Thomas Bley wrote on 13.02.2015 21:51: Hi all

Re: [PHP-DEV] [RFC][VOTE] Improve array to string conversion

: On 24 February 2015 at 19:23, Thomas Bley ma...@thomasbley.de wrote: I think this is a huge bc break that will affect many applications. For example: // test.php error_reporting(E_ALL ~E_NOTICE); echo $_GET['value']; curl http://.../test.php?value=foo // ok curl http://.../test.php?value

Re: [PHP-DEV] [RFC] Anonymous Classes

here is an example for opening a mysqli connection only when the first query is executed: $c = new class extends mysqli { public function query($query, $resultmode = MYSQLI_STORE_RESULT) { if (empty($this-host_info)) parent::real_connect('127.0.0.1', 'user', 'pwd', 'db'); return

Re: [PHP-DEV] [RFC] Anonymous Classes

I'm not sure if json syntax is better than PHP here: $object = (object)[ 'property'=$value, 'method'=function(){...} ]; $object-property; $object-method-__invoke(); S.A.N wrote on 24.02.2015 19:37: Would have been more useful, inline sintex like JSON: $object = { 'property':

Re: [PHP-DEV] [RFC][VOTE] Improve array to string conversion

I think this is a huge bc break that will affect many applications. For example: // test.php error_reporting(E_ALL ~E_NOTICE); echo $_GET['value']; curl http://.../test.php?value=foo // ok curl http://.../test.php?value[0]=foovalue[1]=bar // application continues with E_NOTICE curl

[PHP-DEV][RFC][VOTE] Enable error_handler callback parameters to be passed by reference

Hi all! we'd like to initiate a vote on Allow error_handler callback parameters to be passed by reference: https://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference We are proposing to enable error_handler callback parameters to be passed by reference to be able to append

Re: [PHP-DEV] [VOTE] Scalar Type Hints

I think the consensus is not so far away. As far as I understand the rules, it is possible to vote yes and put up a new RFC to remove strict-declare after the voting ends? Regards Thomas Andi Gutmans wrote on 06.02.2015 00:22: I have to say I’m pretty disappointed at the opening of the vote.

Re: [PHP-DEV] What do we need strict scalar type hints for?

I would prefer: function addVat($amount) { validateAmount($amount); return round($amount*1.19, 2); } function validateAmount($amount) { if (!is_int($amount) !is_float($amount)) { throw new InvalidArgumentException('Argument amount must be of the type int|float, '.gettype($amount).'

Re: [PHP-DEV] What do we need strict scalar type hints for?

Here is a typical billing example which uses exceptions: ?php ini_set('error_reporting', E_ALL); ini_set('display_errors', 1); addVat('apples'); function addVat($amount) { if (!is_int($amount) !is_float($amount)) { throw new InvalidArgumentException('Argument 1 passed to '.__FUNCTION__.'

Re: [PHP-DEV] What do we need strict scalar type hints for?

Yes, we currently have negative values for invoices and positive for vouchers ... Christoph Becker wrote on 02.02.2015 22:17: Thomas Bley wrote: Here is a typical billing example which uses exceptions: ?php ini_set('error_reporting', E_ALL); ini_set('display_errors', 1); addVat

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

what about giving several voting options? yes/no for scalar type hints and yes/no for declare-strict Regards Thomas Michael Wallner schrieb am 2. Feb 2015 09:49: On 02 02 2015, at 00:49, Andrea Faulds a...@ajf.me wrote: Good evening, The RFC has been updated to cover return types,

Re: [PHP-DEV] Enable error_handler callback parameters to be passed by reference

'.$errline); return true; } Regards Thomas Dan Ackroyd wrote on 30.01.2015 10:38: On 21 January 2015 at 04:39, Thomas Bley ma...@thomasbley.de wrote: In userland it is sometimes necessary to extend PHP's notices/warnings with additional information (e.g. username from session, stack trace, etc

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

Hi, the idea behind the rfc is not to change error messages, it's only to append useful information to them. Regards Thomas Andrea Faulds wrote on 28.01.2015 17:53: Hi Thomas, On 27 Jan 2015, at 02:45, Thomas Bley ma...@thomasbley.de wrote: Here is the rfc: https://wiki.php.net/rfc

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

on 28.01.2015 18:38: Hi Thomas, On 28 Jan 2015, at 17:36, Thomas Bley ma...@thomasbley.de wrote: the idea behind the rfc is not to change error messages, it's only to append useful information to them. That’s still changing the message. Error handlers are global anyway, so this is useless

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

I think you mean: function myErrorHandler( int $errno , string $errstr [, string $errfile [, int $errline [, array $errcontext [, string $extra_errstr ) We have these empty-call-filled-on-return parameters in preg_match(...$match) but I am not sure if it makes things more complicated than

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

User defined error handler is for error handling customization, letting user customize message makes sense. This is exactly our case. Thomas, If there are many people concerns to change error message, how about append user error message to original error message when it's changed? It's a

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

and it was never useless or dangerous. Regards Thomas Thomas Bley wrote on 28.01.2015 18:50: Error handlers are global anyway, so this is useless (or dangerous) for libraries. Yes that's true, maybe set_error_handler can be changed so it behaves like register_shutdown_function or spl_autoload_register

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

, 2015 at 2:11 PM, Thomas Bley ma...@thomasbley.de wrote: There are some workarounds with register_shutdown_function to extend E_ERROR messages, but I think that's quite dirty in a system with many parallel requests. Here is an example: ?php ini_set('error_reporting', E_ALL); ini_set

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

: {action:edit} Regards Thomas Xinchen Hui wrote on 27.01.2015 13:26: Hey: On Tue, Jan 27, 2015 at 11:08 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Thomas, On Tue, Jan 27, 2015 at 11:45 AM, Thomas Bley ma...@thomasbley.de wrote: Here is the rfc: https://wiki.php.net/rfc

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

Hi, the idea behind the rfc is not to change error messages, it's only to append useful information to them. Changing lines/filenames is surely something controversial and might be only useful when compiling configuration files or templates to php code. Therefore we have 3 options in the

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

Here is the rfc: https://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference Thanks to reeze for coding and putting it on the wiki. Regards Thomas reeze wrote on 23.01.2015 10:59: Yeah, seem other want it it too, so I just updated the PR to allow the first four

Re: [PHP-DEV] User defined session serialize handler

Sessions take a big amount of data in production systems, so it might be worth to use msgpack (or others) as an option. Regards Thomas Yasuo Ohgaki wrote on 24.01.2015 03:28: Hi all, Session module has session serializer modules that serializes $_SESSION back and forth. Session

Re: [PHP-DEV] Enable error_handler callback parameters to be passed by reference

/php/php-src/pull/1018 the PR is against master, but I think this could also been in 5.5. On 22 January 2015 at 18:41, Yasuo Ohgaki yohg...@ohgaki.net mailto:yohg...@ohgaki.net wrote: Hi Thomas, On Wed, Jan 21, 2015 at 1:39 PM, Thomas Bley ma...@thomasbley.de mailto:ma

[PHP-DEV] Enable error_handler callback parameters to be passed by reference

In userland it is sometimes necessary to extend PHP's notices/warnings with additional information (e.g. username from session, stack trace, etc.) I'm proposing to enable error_handler callback parameters to be passed by reference to be able to append additional data to error messages. Example:

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

For me personally, I would use strict hints for private/protected methods and weak hints for public methods. Regards Thomas Thomas Bley wrote on 15.01.2015 21:16: What about doing both weak and strict with two different syntaxes? public function __construct(string $name, $age as int

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

What about doing both weak and strict with two different syntaxes? public function __construct(string $name, $age as int, $cuteness as float, bool $evil) { string $name // strict $age as int // weak $cuteness as float // weak bool $evil // strict as Syntax is taken from SQL92. Regards Thomas

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

). Regards Thomas Rowan Collins wrote on 15.01.2015 23:09: On 15 January 2015 20:16:54 GMT, Thomas Bley ma...@thomasbley.de wrote: What about doing both weak and strict with two different syntaxes? public function __construct(string $name, $age as int, $cuteness as float, bool $evil) { string

  1   2   >