[PHP-DEV] Allow __toString() to throw exceptions

Hi, There has been no feedback on this bug for a while: https://bugs.php.net/bug.php?id=53648 @aharvey said : > Should there ever be a Zend Engine 3, however, this could be revisited. Now would be the perfect time to fix it then, it would add to the list of error-handling improvements

RE: [PHP-DEV] Allow __toString() to throw exceptions

> Hi Benjamin. Hi Janub, > I have a question: is there any reason to throw an exception from __toString, > other than a non-recoverable error, which would denote that the object, which > the __toString method is called on, does not have any meaningful string > representation? Because if

Re: [PHP-DEV] Proposal: native decimal scalar type support

Le mer. 26 avr. 2023 à 12:29, Alexander Pravdin a écrit : > As a user, I want to have native decimal scalar type support. > For what it’s worth, this is already solved in userland: https://github.com/brick/math Now having always-available support for arbitrary precision math in the language, w

Re: [PHP-DEV] Possible RFC: PDOStatement::addBatch

On Wed, 14 Jun 2023 at 01:41, Vinicius Dias wrote: > Hello, folks. I hope you all are well. > > I was talking to friend about a feature I would like to see in PHP but > I mentioned that unfortunately I do not have the knowledge to try > implementing it myself, since it is not something very simpl

Re: [PHP-DEV] Reflection*::hasAttribute()

> > I think that would require an RFC. > > To clarify, you're proposing to replace this: > > count((new ReflectionClass(Beep::class))->getAttributes(Ignore::class)) == > true > > with > > (new ReflectionClass(Beep::class))->hasAttribute(Ignore::class) > > Right? That doesn't seem like a huge impro

Re: [PHP-DEV] Previous discussions about generics syntax only?

Hi, yes there was, back in 2020: https://externals.io/message/111875 - Benjamin On Mon, 16 Oct 2023 at 16:08, Olle Härstedt wrote: > Hello internals, > > Was there a previous discussion about the pros/cons of adding only the > syntax needed for generics, but not the functionality? So static > a

Re: [PHP-DEV] Two new functions array_first() and array_last()

On Wed, 18 Oct 2023 at 17:05, Robert Landers wrote: > > This is simply not true, 0 is not always the first key in a list, > especially after filtering it. Hence there is a need for this function > in the first place. Just to clarify this point: If 0 is not the first key, then it's not a list. A

Re: [PHP-DEV] Two new functions array_first() and array_last()

On Wed, 18 Oct 2023 at 17:47, Levi Morrison wrote: > > I don't see how `array_is_list` is relevant to `array_first` and > `array_last`. PHP arrays are ordered: > > $foo = [ > "first" => 1, > "third" => 3, > ]; > > It would be perfectly fine to use `array_first` or `array_l

Re: [PHP-DEV] [RFC] [Vote] Type Guards for Classes

On Thu, 16 May 2024 at 22:33, Patrik Václavek wrote: > Introduction > * > > This RFC proposes a new feature in PHP: type guards for classes (or > interfaces). This feature aims to simplify and standardize the process of > verifying that a variable is an instance of a specific class, e

Re: [PHP-DEV] Add bcdivmod() to BCMath

Hi, I've been working on improving performance of BCMath lately, and I found > that I can get the div and mod in one calculation. This is obviously faster > than calculating it twice separately. > > Do you think there's a demand for this feature? > > e.g. > ``` > [$quot, $rem] = bcdivmod('123', '2

Re: [PHP-DEV] Add bcdivmod() to BCMath

> > I see, I understand. > > But I don't think that's wise. For example, if we reversed the order of > the div and mod, there would be no cache and we wouldn't get the speed > boost. (Or does it cache the quotient as well?) > I don't think the cache is a good idea either, for the reasons you menti

Re: [PHP-DEV] [low priority] WeakMaps with scalar keys

> > The answer is: it depends. If you don’t need the array to clean up after > itself, you can indeed use an array of WeakReference to get most of the way > there. If you want it to clean up after an object gets removed, you either > need to add support to the stored object’s destructor (which isn’

Re: [PHP-DEV] [RFC] Arrow functions / short closures

This makes me thinking, has this syntax been considered? ($x) => { $x * $y } Nested: ($x) => { ($y) => { $x * $y } } AFAICS, we don't need the brackets around the whole expression, as this should be parsable without any ambiguity; and the syntax would be closer to that of JavaScript. On Thu,

Re: [PHP-DEV] [RFC] Arrow functions / short closures

oblem: I have yet to see array keys enclosed with parentheses in PHP codebases. On Thu, 14 Mar 2019 at 15:54, Rowan Collins wrote: > On Thu, 14 Mar 2019 at 14:12, Benjamin Morel > wrote: > > > This makes me thinking, has this syntax been considered? > > > > ($x) => { $x *

Re: [PHP-DEV] Re: [RFC] Permit trailing whitespace in numeric strings

FWIW, I'd lean towards rejecting leading whitespace. That could be a good BC break candidate for PHP 8! Ben On Fri, 22 Mar 2019 at 00:33, Andrea Faulds wrote: > Hi again, > > I would proceed to a vote with this (and do intend to still), but the > response from internals has been very quiet. Has

Re: [PHP-DEV] Re: [RFC] Permit trailing whitespace in numeric strings

On Tue, 26 Mar 2019 at 21:33, Theodore Brown wrote: var_export("50" == " 50"); // true > I almost had a heart attack after running this code. I knew that PHP had a few quirks when comparing different types, but I had long taken for granted that comparing 2 *strings *performed a byte-by-byte comp

Re: [PHP-DEV] Re: [RFC] Permit trailing whitespace in numeric strings

ing on such quirks if you ask me. Also, may I suggest that these 2 RFCs be merged together? https://wiki.php.net/rfc/string_to_number_comparison https://wiki.php.net/rfc/trailing_whitespace_numerics Ben On Tue, 26 Mar 2019 at 23:28, Rowan Collins wrote: > On 26/03/2019 21:54, Benjamin Morel wrote

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

handle implicit conversions here. It's so much more understandable, easy to remember, and less prone to errors IMO. Ben On Wed, 27 Mar 2019 at 11:28, Claude Pache wrote: > > > > Le 27 mars 2019 à 00:09, Benjamin Morel a > écrit : > > > > - I would also strongly

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

dicated string concatenation operator, removing any ambiguity around the + operator. This does not mean that we cannot borrow their semantics for string/number *comparison*! Ben On Wed, 27 Mar 2019 at 15:26, Claude Pache wrote: > > > Le 27 mars 2019 à 14:29, Benjamin Morel a >

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

wed from JS, suggested below? Ben On Wed, 27 Mar 2019 at 16:21, Claude Pache wrote: > > > Le 27 mars 2019 à 16:14, Benjamin Morel a > écrit : > > > Sure, PHP has the huge advantage here to have a dedicated string > concatenation operator, removing any ambiguity around the

Re: [PHP-DEV] random_seed()

Seeds could even be dangerous here, as these numbers are supposed to be cryptographically secure. If you need a seedable PRNG for testing, just use rand(). Ben On Mon, 1 Apr 2019 at 09:57, Pierre Joye wrote: > Good afternoon, > > fully correct. Seeds are not needed anymore. > > > best, > > On

[PHP-DEV] PHP_FLOAT_MIN is positive

Hi internals, I just used PHP_FLOAT_MIN for the first time, and was surprised that it is the smallest **positive** number representable. Is this expected? This is unlike PHP_INT_MIN, which is the absolute smallest representable integer, and as such is negative: echo PHP_INT_MIN; // -922337203685

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

03/04/2019 12:27, Diogo Neves wrote: > > It really don't make much sense: > > > > > > > var_dump( PHP_FLOAT_MIN < 0 ); > > var_dump( PHP_INT_MIN < 0 ); > > > > On Wed, Apr 3, 2019 at 10:52 AM Benjamin Morel > > > wrote: > > > >> Hi i

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

What about going forward with the trailing whitespace RFC right now, but ask to vote between 3 options? - NO - leave as it is - YES - allow trailing whitespace - YES - disallow leading whitespace And then proceeding with the string to number comparison RFC? Ben On Thu, 4 Apr 2019 at 01:15, Andr

Re: [PHP-DEV] Question about adding !function_identifier

> > Quite honestly knowing that a function “throws” but not *what* it throws, > is useless. > Now if it were a proposal to add *runtime checked* `throws FooException, > BarTypeError` or similar, I could get behind. Same here. On Thu, 4 Apr 2019 at 02:48, Stephen Reay wrote: > > > > On 4 Apr

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

w leading whitespace sane people > > On Thu, Apr 4, 2019 at 1:57 AM Benjamin Morel > wrote: > >> What about going forward with the trailing whitespace RFC right now, but >> ask to vote between 3 options? >> >> - NO - leave as it is >> - YES - allow

Re: [PHP-DEV] Question about adding !function_identifier

> > Yes, I think we are rapidly approaching the limit where to make the > language stricter, we need an official static analysis tool, like Hack has, > rather than trying to do everything at run-time. It might even be possible to build this into OpCache somehow, so that if > you pre-analyse your

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

Thanks for bringing this new serialization method to PHP 7.4, Nikita! It would be nice if we could make this reusable beyond serialization. There > are two caveats that come to mind: > (...) > The __unserialize() method assumes an already constructed object on > which __unserialize() can be called

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

> register_cast_function('?int', 'castToIntOrNull'); I would quite oppose such a generic implementation, as it might have unexpected consequences in other parts of the codebase : it's a global configuration set at runtime. I quite like the idea of nullable casting though, as I've come across a fe

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

"" != "0"`. Ben On Mon, 8 Apr 2019 at 12:25, Stephen Reay wrote: > > > On 8 Apr 2019, at 16:35, Benjamin Morel > wrote: > > > >> register_cast_function('?int', 'castToIntOrNull'); > > > > I would quite oppose such

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

> > I should probably clarify what I mean by explicit and implicit here. By > explicit I mean anything using (int) casts or doing so internally > (implicitly ^^) -- this *must* produce an integer in some way and does not > have the option of rejecting the input. By implicit I mean other places > ch

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

I think that the RFC covers a great deal of possible syntaxes and their tradeoffs. `==>` requires *a lot* of changes to the current parser, and external tooling as mentioned by Rowan. It has not even been specified whether the `==>` syntax could land into PHP 7.4, or could require postponing to P

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

> > I'm somewhat split on this one. > On the one hand, if I make an explicit cast, my intention is clear, make > the best attempt to convert this string into a number. Trimming > whitespace would be a natural consequence of that. > On the other hand, I'm a stickler for consistency. > On the balance

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

> > I'm a bit concerned that there are two possible semantics for what (?int) > does: There is only one, if we align the semantics of explicit and implicit casting: you wouldn't expect this: function test(?int $bar) { var_export($bar); } test("abc"); ...to output 'null'? -- Ben

[PHP-DEV] Unset static properties

Hi internals, I came across this when playing with static properties: class A { public static int $x; } // This throws, as expected: // Error: Typed static property A::$x must not be accessed before initialization echo A::$x; // Once we initialize the property:

Re: [PHP-DEV] Unset static properties

> We could add support for this, but as the general consensus is that we'd much rather remove support for unsetting declared object properties (if we could cover the lazy loading use case in a different way), I don't think it makes sense to allow this. Ok, thanks. Just wanted to double check. Not

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

> > I believe returning null in those situations makes the most intuative > sense, yes. No offense, but how can casting semantics different from those already used in implicit casting be intuitive? function a(int $x) { var_export($x); } function b(?int $x) { var_export($x); } a("12

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

IMHO a bad idea which does not help moving the language towards better consistency. - Ben On Wed, 10 Apr 2019 at 18:55, Mark Randall wrote: > On 10/04/2019 17:15, Benjamin Morel wrote: > > No offense, but how can casting semantics different from those already > used > > in impl

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

r explicit and implicit cast as inconsistencies. - Ben On Wed, 10 Apr 2019 at 20:01, Mark Randall wrote: > On 10/04/2019 18:34, Benjamin Morel wrote: > > So why would you have different semantics for implicit `(?int)` cast vs > `: > > ?int` function return type cast, if they

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

> yes php still suffers of > it's java-like-transform; historically named php5; > repeating the same design traps almost 20 years after it; Maybe you could just switch to another language then, and bother another mailing list? On Thu, 11 Apr 2019 at 16:51, M. W. Moe wrote: > @Stephen Reay > >

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

> why? if voicing reasonable criticisms is bothering you; then you should do something else in life; > because engineering is built on this `very` concept; You're very welcome to challenge the "java impurities" that have been a foundation of the language for 15 years—although you may better invest

Re: [PHP-DEV][DISCUSSION] Multilingual PHP

The problem with this approach is that while it may become more readable for the native speaker, it becomes pretty much impossible to read for the rest of the world. Having one single syntax for everyone allows all programmers in the world to share code. I can't imagine a world where I'd find a lib

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

Even though I was originally hoping for something closer to JS syntax, considering Nikita's summary it looks like the best contender is still fn(), as originally proposed. At least it looks like a function indeed, to the uninitiated. So FWIW, I think that a vote for the fn() syntax only still make

[PHP-DEV] Object Type Casting Reloaded

Hi internals, I'd like to revive an old discussion about object type casting. The idea would be to allow (ClassName) casting: $service = (EmailService) $diContainer->get('email.service'); The above code would throw a TypeError if the value is not an inst

Re: [PHP-DEV] Object Type Casting Reloaded

VM does not care what the type is before attempting to access one of its members. But I'm not sure if the fact that we miss the "conversion" part is enough to justify a change in naming or syntax compared to the Java equivalent? - Ben On Tue, 23 Apr 2019 at 00:03, Larry Garfield wro

Re: [PHP-DEV] Object Type Casting Reloaded

Hi Azjezz, thanks for jumping in! > I have been using HackLang for quite a while now and i believe they have a better solution for this, and it would awesome to see it in PHP, the `as` operator. If I understand correctly, `as` is an operator that performs type checks but never casts like () does.

Re: [PHP-DEV] Object Type Casting Reloaded

php> ( mixed > < > https://www.php.net/manual/en/language.pseudo-types.php#language.types.mixed > > > $offset ) : mixed > < > https://www.php.net/manual/en/language.pseudo-types.php#language.types.mixed > > > $service = $diContainer['email.service'] of

Re: [PHP-DEV] Object Type Casting Reloaded

>> btw I'm sure you're already aware of it, but this is using a > >> 'dependency injector' as a service locator. If your current DI library > >> isn't powerful enough for you, rather than abusing it like this, I'd > >> recommend looki

Re: [PHP-DEV] Object Type Casting Reloaded

@Mark Randall > It keeps coming back to the feature we've all been praying to the PHP > Gods for... generics. > $x = cast($obj); I did not think about using generics for this, but indeed this could work. It's only reasonably verbose, easily implemented in userland, and should be usable both by s

Re: [PHP-DEV] Object Type Casting Reloaded

@Stephen Reay > And as I said before, I can’t understand how that is supposed to be better than just doing what works now, using instanceof to check the type inside the block: > if (! $foo instanceof Foo) { throw new TypeError(…); } > At least with the above, it’s obvious what is happening. It's

Re: [PHP-DEV] Object Type Casting Reloaded

@Stephen Reay > In languages without type hinting (e.g. JavaScript) - the “boiler plate” you’re trying to remove is also common, e.g. using `typeof` in JavaScript. It's also very common to *not* check types in JavaScript... I assume the absence of type hints is partly responsible for this, and a

Re: [PHP-DEV] Make bcmath functions more strict

Hi Vladyslav, I just checked your code snippet, here are my 2 cents: - bcmath should definitely trigger an error when encountering a malformed string like '17 .123', silently converting it to zero is indeed the worth thing to do; - I don't think that there's much value in having it handle exponen

Re: [PHP-DEV] Make bcmath functions more strict

Hi Vladyslav, > I don't really understand it, I must be strict, converting to zero > will lead to wrong calculations. That's what I said :) Fully agree here, any non-numeric string should throw an exception. In summary, I would check that the string matches ` /^[\+\-]?[0-9]+(\.[0-9]+)?$/`or else

Re: [PHP-DEV] Make bcmath functions more strict

> Throwing an exception would be rather uncommon for functions, and would > definitely have to wait for PHP 8 for BC reasons. Sure. This is actually a discussion I'd like to start for all PHP functions in PHP 8. >Another option might > be to introduce an object-oriented layer on top of libbcmath.

Re: [PHP-DEV] Make bcmath functions more strict

> Yes, PHP 8 for BCs and PHP 7.4 for warnings that's what I was trying to said FWIW, I don't think anyone will complain about adding a warning to something that's obviously a bug when it fails. I'd say go ahead a write an RFC. If you want to have more chances for it to pass though, I would not cha

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

> I don't even mind still having a compile error in PHP 8 when it sees the token I don't have a vote so these are just my 2 cents, but even though I'm all for removing short open tags entirely, I think that this solution is excellent for 2 reasons: - it solves the code leak issue when upgrading b

Re: [PHP-DEV] Add get_mangled_object_properties()

I like the explicitness of the proposal, but only if performance is as good as (array) cast. One of the reasons we use casting to array in libraries is not only to access all properties at once, but also because it's fast as it's implemented as an opcode and not a function call. Would this function

[PHP-DEV] Allow zero parameters in array_merge()?

Hi Internals, I'm wondering if there's any reason why array_merge() doesn't allow zero arrays to be passed? array_merge(); // Warning: array_merge() expects at least 1 parameter, 0 given It would be reasonable IMO to return an empty array in this case. The reason is, I'm often using it this

Re: [PHP-DEV] Allow zero parameters in array_merge()?

> Already the case in PHP 7.4 This, will teach me to scroll down the page. Thank you! Ben

Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures

> > ""M. W. Moe"" wrote > > If you do not accept any rational criticism; you should think of doing > > something else; I do not know; gardening maybe? who knows. > > > > P.S For my use of the "closure" you made a fool yourself beyond what you > > can grasp; but anyhow, my dear, it's refreshing, yo

Re: [PHP-DEV] Generating arginfo from stub files

> > But also, it's really a shame we don't have the union types RFC passed > yet, as it means that the return type for a significant number of > functions will be either incomplete or misleading. > > Agreed.

Re: [PHP-DEV] [Discussion] Scalar Object Strings and Multibyte Encodings

This reminds me of the discussions around PHP 6 :-) Without commenting on scalar objects (which looks promising), it would be nice if PHP could also ship with a *non-disableable* multibyte extension (most likely mbstring, which I think is more widespread than iconv). Currently a lot of code has to

Re: [PHP-DEV] [RFC] Strict operators directive

Impressive work indeed, this would be a perfect addition to strict_types that would remove a lot of WTFs while preserving BC with older code. Please note that the formatting of the RFC is broken after the Bitwise Operators section. Ben

Re: [PHP-DEV] Re: Checkout phpdoc

By the way, is there any work in progress to migrate the PHP manual to Git? The docs only say: The PHP manual is still currently hosted on SVN, although it will be > migrated to Git in the future. I'd love to be able to fix things in the PHP manual with a simple PR;

Re: [PHP-DEV] Re: Checkout phpdoc

Can't wait to try it, thanks for the pointer! Ben On Tue, 25 Jun 2019 at 23:48, G. P. B. wrote: > On Tue, 25 Jun 2019 at 23:41, Benjamin Morel > wrote: > >> By the way, is there any work in progress to migrate the PHP manual to >> Git? >> The docs <h

Re: [PHP-DEV] [RFC] Strict operators directive

>"120" > "99.9"; // TypeError > Anything else will bring confusion. Not sure about this, you can do it the JS way: if both operands are strings, then it behaves like strcmp(): "23" > "4"; // false "23" > "221"; // true I'm not saying that we should do it, but this would not be confusing to m

Re: [PHP-DEV] Re: Checkout phpdoc

> There is a small team of people currently working on moving the docs to git. > Due to the tight integration of SVN into the workflow it's not as easy as we all thought to do the actual move. > For more infos feel free to head over to https://github.com/phpdoctest/meta Thanks for the link! This l

Re: [PHP-DEV] [RFC] Strict operators directive

> (...) could be the case depending on a declaration somewhere else in the source code. > That's the confusion Claude and I were talking about: You cannot be sure what a very simple line of code does. Oh, I see. You mean that only replacing some of the current results with TypeErrors would be acc

Re: [PHP-DEV] [RFC] Strict operators directive

> * in some strict mode, reserve `<`, `==` etc. for numeric comparison, and throw a TypeError one of the operand is not numeric; > * If we deem it worth, define a new operators for string comparison. (Although I’m not really sure it is worth: we have `strcmp()` and `===` for byte-to-byte compariso

Re: [PHP-DEV] [RFC] Strict operators directive

> > Given that we already have === and !==, could the strict mode simply throw > an error for *any* use of the non-strict == and != versions? > declare(strict_operators=1); > var_dump( "11" == "11.0" ); # TypeError: "Cannot use non-strict equality > operator in strict operator mode." > var_dump( "

[PHP-DEV] Memory leak in eval()'d code

Hi internals, I've tracked down a memory leak to an anonymous class created within eval(): ``` for ($i = 0; $i < 100; $i++) { $object = eval('return new class {};'); if ($i % 1000 == 0) { echo memory_get_usage() . "\n"; } } ``` The memory usage quick

Re: [PHP-DEV] Memory leak in eval()'d code

blem. Thank you, Ben On Fri, 28 Jun 2019 at 17:59, Johannes Schlüter wrote: > On Fri, 2019-06-28 at 02:41 +0200, Benjamin Morel wrote: > > Hi internals, > > > > I've tracked down a memory leak to an anonymous class created within > > eval(): > > > >

Re: [PHP-DEV] Memory leak in eval()'d code

> > That's not a "leak". You create new objects (in this case, classes), > they take memory. Why do they not "leak" memory without eval() then? Replace with `$object = new class {};` and memory usage stays flat. There has do be some kind of garbage collection for these anonymous classes. Ben

Re: [PHP-DEV] Memory leak in eval()'d code

> As Johannes already pointed out, we cannot garbage collect anonymous class definitions due to the existence of opaque references. I still don't understand *why*, then, the memory stays flat when the new class does not happen in eval(): ``` for ($i = 0; $i < 100; $i++) { $object = ne

Re: [PHP-DEV] Memory leak in eval()'d code

> The problem here is that OP is *creating* many classes (the fact that they are anonymous ultimately doesn't matter) by eval'ing code. That is what causes the leak. I still don't understand why there is no leak when *not* using eval(), though. Ben

Re: [PHP-DEV] Memory leak in eval()'d code

> > What is the "non scaled case"? To repeat what I said earlier: Without eval > there is no and will not be a leak. > The bug is that eval() currently reuses an existing class instead of > creating a new one each time. Calling get_class(eval("return new class > {};")) should be returning a new str

[PHP-DEV] WeakReference: WeakMap / GC callbacks

Hi internals, I'm following up on a message by Andrea Faulds on Feb 4, 2019 : Have you considered adding a WeakMap type as well — a map of (object) > keys to values where the keys are weakly referenced? This is a useful > construct based on weak referen

Re: [PHP-DEV] Re: Bringing Peace to the Galaxy

> > I'm going to speak strictly as a userland PHP developer, for that is > what I am. > The idea of PHP being held hostage to eternal backwards compatibility > fills me with absolute dread. > (...) > I can deal with short term pain for long term gain. > What I would struggle to deal with is committ

Re: [PHP-DEV] Call for participation: Annotating internal function argument and return types

Hi, Sorry if I’m missing something, but can’t the process be automated? i.e. parse the C source files with a script to generate the stubs? If correctly done, this could be much less error-prone than manual handling. Benjamin > Le 10 août 2019 à 14:00, Stephen Reay a écrit : > -- PHP Intern

[PHP-DEV] get_class_vars() and typed properties

Hi Internals, I just noticed the following behaviour: class A { public int $a; public ?int $b; public ?int $c = null; } $a = new A; var_export(get_object_vars($a)); var_export(get_class_vars('A')); Result: array ( 'c' => NULL, )

Re: [PHP-DEV] RFC: var_export - short syntax for array

> > There are other issues with the format besides just the long array syntax. > E.g. opening bracket on same line? Indentation? For the record, I have a userland implementation of var_export() that does all of this: - (object) array export of stdClass for PHP < 7.3 - short array syntax - bracke

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

I've thought about this many times while reading messages on internals, but from another perspective: the inability to "+1" a message without having to reply. I very often find myself agreeing (or disagreeing) with someone, but refrain myself from posting a one-liner to show my support. Having some

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

> > As a code collaboration platform, GitHub is pretty good, but it's not built > as a discussion forum, and there are plenty of limitations to using it as > one. Could we work on agreeing on a set of requirements for such a discussion "forum" to replace mailing lists? That would make it easier f

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

> > That's pretty much the opposite of your previous question. For one thing, > it's unanswerable without knowing the scope - e.g. would it just be for > RFCs, or all discussions? I'm thinking about a generic "forum" for all discussions that happen on the mailing lists right now, something that c

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

> > declare(sloppy=1); I like this idea. Strict by default, sloppy by (code-level) config.

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

> > For example when I’m writing a throw-away script, some notices are okay to > indicate possible problems Maybe it's just me, but even in throw-away scripts, *I've lost much more time because of warnings/notices going unnoticed, than I've saved thanks to PHP's forgiving nature*. Hence even in t

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

>> $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1; > That violates blatantly DRY (twice the exact same lengthy expression `$foo[$key1][$key2]`), so it is not a satisfactory solution. $foo[$key1][$key2]??++ 😃 More seriously, yes as Marco suggested, yes we can already do it, and as Claude point

Re: [PHP-DEV] Re: [RFC] Union Types v2

Hi Nikita, Thank you for your work on this, I look forward to being able to use union types! The one thing that bothers me a bit is introducing yet another inconsistency by supporting false and not true as a type. Sure, I do get the need for false as a valid type for historical reasons, but at th

Re: [PHP-DEV] [RFC] Union Types v2

> I would tend to agree with Sara. That seems to be the only issue of contention and it is (AFAIK) reasonably straightforward to add "later" without blocking the rest of Union types. It would mean some functions wouldn't be able to get a fully accurate return type yet but... they've survived thi

Re: [PHP-DEV] [RFC] Union Types v2

> While certainly not the primary reason for why we should support union types, the reason why I brought this proposal forward at this time specifically, is that the lack of union types is a blocker for my pet project of providing comprehensive type annotations for internal functions. Supporting "f

[PHP-DEV] Error when POST / upload limits are exceeded

Hi internals, One thing that always bugged me is how PHP silently ignores data that exceeds the limits defined in php.ini. For example, posting a form exceeding post_max_size results in empty $_POST and $_FILES, with no error message whatsoever. This has bugged a few more people than just myself,

Re: [PHP-DEV] Error when POST / upload limits are exceeded

> We have https://www.php.net/manual/en/features.file-upload.errors.php but in general this is not so easy to make more convenient because this runs before your PHP code starts to run, so it is not like you can stick it in a try/catch. Hi Rasmus, These errors are only relevant when you have somet

Re: [PHP-DEV] Error when POST / upload limits are exceeded

> Perhaps a more generic $_SERVER['PHP_REQUEST_STATUS'] or something along those lines where you'd put the error message from https://www.php.net/manual/en/features.file-upload.errors.php as well. And add new states for these exceeded limits that aren't caught there. It would be nice if you just ne

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

> Which is why ANY unnecessary changes that need to be made as a > result are just painful often without ANY gain what so ever on either side? One gain that's very often overlooked on this list, is teaching a better PHP to new generations. It IS confusing if PHP has more than one way to do one thi

Re: [PHP-DEV] Constraints and userland@

> > As a part of PHP community I like the idea. I'd propose something that > could make the > proposal simpler in implementation. > Create a poll system where users are authorized to be registered and be > able to vote if > they are github/gitlab users with >1000 commits in projects where PHP is >

Re: [PHP-DEV] Constraints and userland@

to me. Thoughts? — Benjamin On Thu, 10 Oct 2019 at 19:09, Chase Peeler wrote: > > > On Thu, Oct 10, 2019 at 3:30 AM Benjamin Morel > wrote: > >> > >> > As a part of PHP community I like the idea. I'd propose something that >> > could make the >&

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

> > As people have expressed interest in hearing about direct technical > benefits that these kinds of changes have ... let me give you an example > that came up yesterday. Too bad this example comes after the vote has been made, and failed. This would be a very strong argument in favour of usin

Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions

> I'm considering writing an RFC (and a patch) to turn some warning into > exceptions in a number of PHP functions. > I would first like to gather some feedback here. I would *LOVE* if these functions could be fixed, and if I had the almighty merge button at my disposal, I'd press it whenever suc

Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions

> I agree with the distinction described by Nikita. > There are definitely cases where a special return value is still the > best option. I personally like exceptions in all cases, as they allow for fine-grained error handling, for example: ``` try { mkdir('somedir'); } catch (FileExistsExc

Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions

matic error reporting for uncaught errors, that you get almost for free with exceptions and a single try/catch at the top level. — Benjamin On Mon, 21 Oct 2019 at 20:46, Rowan Tommins wrote: > On 21/10/2019 18:45, Benjamin Morel wrote: > > I personally like exceptions in all case

  1   2   3   >