[PHP-DEV] Proposal: restrict the number of filters

Hello, Chaining filters is becoming an increasingly popular primitive to exploit PHP applications: - https://www.synacktiv.com/en/publications/php-filters-chain-what-is-it-and-how-to-use-it.html + https://github.com/synacktiv/php_filter_chain_generator - https://www.synacktiv.com/publications/php

Re: [PHP-DEV] Proposal: restrict the number of filters

On Thu, 7 Nov 2024, jvoisin wrote: > The easiest way to kill this vector is to simply limit the number of > filters that can be chained, as attacks require a at least a couple of > them, while legitimate use usually use one or two tops, as highlighted > by arnaud-lb's analysis: > https://github.co

Re: [PHP-DEV] Proposal: Add support for interactive console application on Windows

On Sep 13, 2024, at 3:24 PM, Christoph M. Becker wrote: > > Note that there are already a couple of related extensions on PECL[1]; > of these only win32service is still maintained, though. Still, having a > look at these extensions might make sense. I actually maintain one for IBM i [1], but it

Re: [PHP-DEV] Proposal: Add support for interactive console application on Windows

On 13.09.2024 at 16:07, Sara Golemon wrote: > On Thu, Oct 12, 2023 at 6:50 PM Patrik Pasterčík wrote: > >> An analysis of other solutions, a detailed description of the problems >> and a proof of concept is in the proposal in the issue here: >> https://github.com/php/php-src/issues/12227 > > Resu

Re: [PHP-DEV] Proposal: Add support for interactive console application on Windows

On Thu, Oct 12, 2023 at 6:50 PM Patrik Pasterčík wrote: > I would like to propose extending PHP with support functions to enable > interactive console work on Windows system. I mean the ability to > control a PHP script running from the console using arrow keys, or > function keys like "F1", etc.

Re: [PHP-DEV] Proposal for New Feature: Multi-level Directory Navigation Function

> I propose the introduction of a new function, upDir(), which simplifies the > process of moving up multiple directory levels in a file path. This function > extends the utility of the existing dirname() by allowing a user to specify > the number of directory levels they wish to ascend in a sin

[PHP-DEV] Proposal for New Feature: Multi-level Directory Navigation Function

Hello, I’m a full stack developer and owner of Truecast that lives in Holley, Oregon, USA. Introduction Navigating up multiple directory levels is a common requirement in PHP applications, especially when managing paths in complex projects. Currently, this is achieved by chaining calls to th

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On 30 April 2024 11:16:20 GMT-07:00, Arvids Godjuks wrote: >I think setting some expectations in the proper context is warranted here. > >1. Would a native decimal type be good for the language? I would say we >probably are not going to find many if any people who would be against it. As I sa

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Tue, 30 Apr 2024 at 09:19, Rowan Tommins [IMSoP] wrote: > > > On 28 April 2024 07:47:40 GMT-07:00, Robert Landers < > landers.rob...@gmail.com> wrote: > > >I'm not so sure this could be implemented as an extension, there just > >isn't the right hooks for it. > > The whole point of my email was

Re: [PHP-DEV] Proposal to Create a MariaDB Alias for the MySQL PDO Driver

On Tue, Apr 30, 2024, at 4:50 PM, Arvids Godjuks wrote: > Hello, > > I'm splitting this discussion from https://externals.io/message/123183, > see details at https://externals.io/message/123183#123234 and > https://externals.io/message/123183#123236 to keep the original thread > clean. > > There

[PHP-DEV] Proposal to Create a MariaDB Alias for the MySQL PDO Driver

Hello, I'm splitting this discussion from https://externals.io/message/123183, see details at https://externals.io/message/123183#123234 and https://externals.io/message/123183#123236 to keep the original thread clean. There's a clear divergence in functionality between MySQL and MariaDB. As PDO

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On 28 April 2024 07:47:40 GMT-07:00, Robert Landers wrote: >I'm not so sure this could be implemented as an extension, there just >isn't the right hooks for it. The whole point of my email was that "this" is not one single feature, but a whole series of them. Some of them can be implemented

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Sun, Apr 28, 2024 at 11:36 AM Rowan Tommins [IMSoP] wrote: > > > > On 28 April 2024 07:02:22 BST, Alexander Pravdin > wrote: > >Hello everyone. To continue the discussion, I'm suggesting an updated > >version of my proposal. > > > This all sounds very useful ... but it also sounds like severa

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On 28 April 2024 07:02:22 BST, Alexander Pravdin wrote: >Hello everyone. To continue the discussion, I'm suggesting an updated >version of my proposal. This all sounds very useful ... but it also sounds like several months of full-time expert development. Before you begin, I think it will b

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Sat, Apr 27, 2024 at 11:04 PM Alexander Pravdin wrote: > > All builtin functions that currently accept float also accept decimal. > So users don't need to care about separate function sets, and PHP > developers don't need to maintain separate sets of functions. If any > of the parameters is de

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

Hello everyone. To continue the discussion, I'm suggesting an updated version of my proposal. The main change is: to use decimal128 as the backend for native decimals, so no 3rd-party libraries are required. Even if adopting a library, it looks like it'll be much easier than the previous proposal.

[PHP-DEV] [proposal] max_execution_time to a negative number

Hello internals, It has come to our attention that max execution time can be set to a negative number, even set_time_limit will happily accept a negative number without error (except when using zend_max_execution_timers in zts mode). I couldn't find, in the docs, how to properly treat a negative

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Tue, Apr 9, 2024 at 7:52 PM Derick Rethans wrote: > Adding a new native type to PHP will create a large change. Not only is > it "just" adding a new native type, it also means all of the conversions > between types need to be added. This is not a small task. I understand this :) > If you wa

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Wed, 3 Apr 2024, Jordan LeDoux wrote: > On Mon, Mar 18, 2024 at 1:35 PM Rowan Tommins [IMSoP] > wrote: > > > > > Where things get more complicated is with *fixed-precision* decimals, > > which is what is generally wanted for something like money. What is the > > correct result of decimal(1.03

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Thu, 7 Dec 2023, Alex Pravdin wrote: > Accounting for all of the above, I suggest adding a native numeric > scalar arbitrary precision type called "decimal". Below are the > preliminary requirements for implementation. Adding a new native type to PHP will create a large change. Not only is

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Tue, Mar 19, 2024 at 5:35 AM Rowan Tommins [IMSoP] wrote: > I think a reasonable number of people do share the sentiment that having two > separate modes was a mistake; and neither mode is actually perfect. It's not > about "making it on by default", it's about coming up with a unified > be

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

Hi Rowan, > Again, I don't think "has more than one attribute" is the same as "feel > almost like objects". But we're just getting further away from the current > discussion, I think. > The proposed class is called BCMath\Number, which implies that every instance > of that class represents a n

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On 8 April 2024 10:12:31 BST, Saki Takamachi wrote: > >I don't see any point in "scalar types" that feel almost like objects, because >it just feels like you're manipulating objects with procedural functions. Why >not just use objects instead? Again, I don't think "has more than one attribut

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Mon, Apr 8, 2024 at 5:06 PM Rowan Tommins [IMSoP] wrote: > If we ever do want to make decimals a native type, we would need some way to > initialise a decimal value, since 1.2 will initialise a float. My original suggestion was: - Add "default decimal" mode with the "declare" statement in t

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

Hi Rowan, > Again, that only seems related to objects because that's what you're used to > in PHP, and even then you're overlooking an obvious exception: array(1, 2) Arrays are a bad example here because their contents are themselves values. For example, it would make sense as an example if th

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On 8 April 2024 01:34:45 BST, Saki Takamachi wrote: > > I'm making these opinions from an API design perspective. How the data is > held internally is irrelevant. zval has a lot of data other than values. What > I want to say is that if multiple types of parameters are required for > initial

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

Hi Rowan > As I replied to Jordan, I don't see why this is connected to "scalar" vs > "object" types at all. An object - particularly an immutable one - is just a > way of declaring a type, and some syntax for operations on that type. There's > really no difference at all between these: > > $h

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On 07/04/2024 14:27, Saki Takamachi wrote: If we really wanted decimal to be a native type, then the rounding mode and scale behavior should be completely fixed and not user selectable. If not, decimal should be implemented as a class. As I replied to Jordan, I don't see why this is connected

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

Hi, > What I'm saying is that $x / 2 doesn't have a good answer if $x is a > fixed-precision number which can't be divided by 2 without exceeding that > precision. You need a third operand, the rounding mode, so you can't write it > as a binary operator, and need some kind of function like decim

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On 04/04/2024 23:31, Jordan LeDoux wrote: Well, firstly most of the financial applications that I've worked in (I work for a firm that writes accounting software right now) do not calculate intermediate steps like this with fixed precision, or even have an interest in doing so. My backgrou

Re: [PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

Le ven. 5 avr. 2024 à 18:04, Larry Garfield a écrit : > On Fri, Apr 5, 2024, at 2:20 PM, Joel Wurtz wrote: > >> Would it make sense to not only add this for ReflectionAttribute, but > also Function and/or others? > > > > There may be case where this makes sense but not necessarily in the use > >

Re: [PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

On Fri, Apr 5, 2024, at 2:20 PM, Joel Wurtz wrote: >> Would it make sense to not only add this for ReflectionAttribute, but also >> Function and/or others? > > There may be case where this makes sense but not necessarily in the use > case that i explain, and don't want to add more to this proposa

Re: [PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

> Would it make sense to not only add this for ReflectionAttribute, but also Function and/or others? There may be case where this makes sense but not necessarily in the use case that i explain, and don't want to add more to this proposal, it's also missing in ReflectionParameter, ReflectionPropert

Re: [PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

Hi Joel On Fri, Apr 5, 2024 at 3:10 PM Joel Wurtz wrote: > > Like a lot of libraries, we offer the possibility to configure behaviors with > Attributes. However in some cases it's wrongly configured by the user and > this wrong configuration cannot be detected on the attribute constructor but

Re: [PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

On Fri, Apr 5, 2024, at 1:09 PM, Joel Wurtz wrote: > Hello everyone, > > Like a lot of libraries, we offer the possibility to configure > behaviors with Attributes. However in some cases it's wrongly > configured by the user and this wrong configuration cannot be detected > on the attribute cons

Re: [PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

On 5 April 2024 15:09:42 CEST, Joel Wurtz wrote: >Hello everyone, > >Like a lot of libraries, we offer the possibility to configure behaviors >with Attributes. However in some cases it's wrongly configured by the user >and this wrong configuration cannot be detected on the attribute >constructor b

[PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

Hello everyone, Like a lot of libraries, we offer the possibility to configure behaviors with Attributes. However in some cases it's wrongly configured by the user and this wrong configuration cannot be detected on the attribute constructor but afterwards. In this case we may want to pinpoint whi

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Thu, Apr 4, 2024 at 2:28 PM Rowan Tommins [IMSoP] wrote: > > > I haven't followed the discussion in the other thread, but I'm not sure > what the use case would be for a "fixed scale decimal" that followed > those rules. > > As mentioned before, the use case I've encountered is money > calcula

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On 04/04/2024 02:29, Jordan LeDoux wrote: But when it comes to fixed-precision values, it should follow rules very similar to those we discussed in the BCMath thread: - Addition and subtraction should return a value that is the largest scale/precision of any operands in the calculation. - Divi

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Mon, Mar 18, 2024 at 1:35 PM Rowan Tommins [IMSoP] wrote: > > Where things get more complicated is with *fixed-precision* decimals, > which is what is generally wanted for something like money. What is the > correct result of decimal(1.03, precision: 2) / 2 - decimal(0.515, 3)? > decimal(0.51,

Re: [PHP-DEV] Proposal: Make $offset of substr_replace null by default

[Aside: please don't use "reply" when starting a new thread. Although GMail and its imitators frequently ignore it, a reply contains a header telling clients where to add it to an existing thread. I've pasted your full text into a new e-mail rather than replying, so it reliably shows as its own

[PHP-DEV] Proposal: Make $offset of substr_replace null by default

substr_replace() has the following signature: substr_replace( array |string $string, array |string

Re: [PHP-DEV] Proposal: AS assertions

On Fri, Mar 22, 2024 at 8:02 PM Rowan Tommins [IMSoP] wrote: > > On Fri, 22 Mar 2024, at 17:38, Claude Pache wrote: > > > Le 22 mars 2024 à 16:18, Rowan Tommins [IMSoP] a écrit > : > > $optionalExpiryDateTime = $expiry as ?DateTimeInterface else > some_other_function($expiry); > assert($optiona

Re: [PHP-DEV] Proposal: AS assertions

On Fri, Mar 22, 2024 at 5:51 PM Rowan Tommins [IMSoP] wrote: > > On Fri, 22 Mar 2024, at 12:58, Robert Landers wrote: > > > >> $optionalExpiryDateTime = $expiry as ?DateTimeInterface else new > >> DateTimeImmutable($expiry); > > I'm not sure I can grok what this does... > > > > $optionalExpiryDat

Re: [PHP-DEV] Proposal: AS assertions

On Fri, 22 Mar 2024, at 17:38, Claude Pache wrote: > >> Le 22 mars 2024 à 16:18, Rowan Tommins [IMSoP] a >> écrit : >> >> $optionalExpiryDateTime = $expiry as ?DateTimeInterface else >> some_other_function($expiry); >> assert($optionalExpiryDateTime is ?DateTimeInterface); // cannot fail, >>

Re: [PHP-DEV] Proposal: AS assertions

> Le 22 mars 2024 à 16:18, Rowan Tommins [IMSoP] a écrit > : > > $optionalExpiryDateTime = $expiry as ?DateTimeInterface else > some_other_function($expiry); > assert($optionalExpiryDateTime is ?DateTimeInterface); // cannot fail, > already asserted by the "as" I think that the `is` operator

Re: [PHP-DEV] Proposal: AS assertions

On Fri, 22 Mar 2024, at 12:58, Robert Landers wrote: > >> $optionalExpiryDateTime = $expiry as ?DateTimeInterface else new >> DateTimeImmutable($expiry); > I'm not sure I can grok what this does... > > $optionalExpiryDateTime = ($expiry === null || $expiry instanceof > DateTimeInterface) ? $expir

Re: [PHP-DEV] Proposal: AS assertions

On 2024-03-22 10:46, Rowan Tommins [IMSoP] wrote: On Fri, 22 Mar 2024, at 08:17, Jordi Boggiano wrote: We perhaps could make sure that as does not throw if used with `??`, or that `??` catches the type error and returns the right-hand expression instead: So to do a nullable typecast you would

Re: [PHP-DEV] Proposal: AS assertions

On Fri, Mar 22, 2024 at 12:01 PM Rowan Tommins [IMSoP] wrote: > > On Fri, 22 Mar 2024, at 08:17, Jordi Boggiano wrote: > > We perhaps could make sure that as does not throw if used with `??`, or that > `??` catches the type error and returns the right-hand expression instead: > > So to do a nulla

Re: [PHP-DEV] Proposal: AS assertions

On Fri, 22 Mar 2024, at 10:05, Robert Landers wrote: > After asking an AI for some examples and usages, the most compatible > one would be C#'s. In actuality, I think it could be hugely simplified > if we simply return null instead of throwing. There'd be no special > case for |null, and it would m

Re: [PHP-DEV] Proposal: AS assertions

On Fri, Mar 22, 2024 at 10:31 AM Jordi Boggiano wrote: > > On 2024-03-21 16:02, Robert Landers wrote: > > $a as int|float > > would be an int, float, or thrown exception. > > $a as int|float|null > > would be an int, float, or null. > > Just a suggestion here which might be more palatable to Rowan

Re: [PHP-DEV] Proposal: AS assertions

On Fri, 22 Mar 2024, at 08:17, Jordi Boggiano wrote: > We perhaps could make sure that as does not throw if used with `??`, or that > `??` catches the type error and returns the right-hand expression instead: > So to do a nullable typecast you would do: > > $a as int|float ?? null > While t

Re: [PHP-DEV] Proposal: AS assertions

On 2024-03-21 16:02, Robert Landers wrote: $a as int|float would be an int, float, or thrown exception. $a as int|float|null would be an int, float, or null. Just a suggestion here which might be more palatable to Rowan's wish for consistency (which I can totally relate to): We perhaps co

Re: [PHP-DEV] Proposal: AS assertions

On 22 March 2024 00:04:27 GMT, Robert Landers wrote: >I think that is where we are getting confused: `null` is a value (or >at least, the absence of a value). The fact that the type system >allows it to be used as though its a type (along with true and false) >is interesting, but I think it is

Re: [PHP-DEV] Proposal: AS assertions

On Thu, Mar 21, 2024 at 11:06 PM Rowan Tommins [IMSoP] wrote: > > On 21/03/2024 19:03, Robert Landers wrote: > > I suppose we are taking this from different viewpoints, yours appears > to be more of a philosophical one, whereas mine is more of a practical > one. > > > My main concern is consistenc

Re: [PHP-DEV] Proposal: AS assertions

> > What's the advantage of a language construct over the following? > > ```php > /** > * @template T of object > * @psalm-assert T $value > * @param class-string $type > */ > function as(mixed $value, string $type): mixed > { > if (! $value instanceof $type) { throw > SomeKindOfException::

Re: [PHP-DEV] Proposal: AS assertions

On 21/03/2024 19:03, Robert Landers wrote: I suppose we are taking this from different viewpoints, yours appears to be more of a philosophical one, whereas mine is more of a practical one. My main concern is consistency; which is partly philosophical, but does have practical impact - the same

Re: [PHP-DEV] Proposal: AS assertions

On Thu, Mar 21, 2024 at 7:01 PM Rowan Tommins [IMSoP] wrote: > > On 21/03/2024 15:02, Robert Landers wrote: > > I don't think you are getting what I am saying. > > $a as int|float > > would be an int, float, or thrown exception. > > $a as int|float|null > > would be an int, float, or null. > > > I

Re: [PHP-DEV] Proposal: AS assertions

On 21/03/2024 15:02, Robert Landers wrote: I don't think you are getting what I am saying. $a as int|float would be an int, float, or thrown exception. $a as int|float|null would be an int, float, or null. I get what you're saying, but I disagree that it's a good idea. If $a is 'hello', b

Re: [PHP-DEV] Proposal: AS assertions

On Thu, Mar 21, 2024, at 3:02 PM, Robert Landers wrote: > I don't think you are getting what I am saying. > > $a as int|float > > would be an int, float, or thrown exception. > > $a as int|float|null > > would be an int, float, or null. > > Robert Landers > Software Engineer > Utrecht NL Hi Rob.

Re: [PHP-DEV] Proposal: AS assertions

On Thu, Mar 21, 2024 at 12:45 PM Rowan Tommins [IMSoP] wrote: > > On 20/03/2024 23:05, Robert Landers wrote: > > In other > words, I can't think of a case where you'd actually want a Type|null > and you wouldn't have to check for null anyway. > > > It's not about having to check for null; it's abo

Re: [PHP-DEV] Proposal: AS assertions

On Thu, Mar 21, 2024 at 12:45 PM Rowan Tommins [IMSoP] wrote: > > On 20/03/2024 23:05, Robert Landers wrote: > > In other > words, I can't think of a case where you'd actually want a Type|null > and you wouldn't have to check for null anyway. > > > It's not about having to check for null; it's abo

Re: [PHP-DEV] Proposal: AS assertions

On 20/03/2024 23:05, Robert Landers wrote: > In other > words, I can't think of a case where you'd actually want a Type|null > and you wouldn't have to check for null anyway. It's not about having to check for null; it's about being able to distinguish between "a null value, which was one of the

Re: [PHP-DEV] Proposal: AS assertions

On Wed, Mar 20, 2024 at 8:30 PM Rowan Tommins [IMSoP] wrote: > > > > On 20 March 2024 12:51:15 GMT, Robert Landers > wrote: > > >Oh and there isn't any difference between: > > > >$x as ?Type > > > >or > > > >$x as Type|null > > > I'm not sure if I've misunderstood your example, or you've misunde

Re: [PHP-DEV] Proposal: AS assertions

On 20 March 2024 12:51:15 GMT, Robert Landers wrote: >Oh and there isn't any difference between: > >$x as ?Type > >or > >$x as Type|null I'm not sure if I've misunderstood your example, or you've misunderstood mine. I'm saying that this should be an error, because the value is neither an in

Re: [PHP-DEV] Proposal: AS assertions

On Wed, Mar 20, 2024 at 1:47 PM Robert Landers wrote: > > On Tue, Mar 19, 2024 at 10:06 PM Rowan Tommins [IMSoP] > wrote: > > > > On 19/03/2024 16:24, Robert Landers wrote: > > > > $x = $attributeReflection->newInstance() as ?MyAttribute; > > if ($x === null) // do something since the attribute i

Re: [PHP-DEV] Proposal: AS assertions

On Tue, Mar 19, 2024 at 10:06 PM Rowan Tommins [IMSoP] wrote: > > On 19/03/2024 16:24, Robert Landers wrote: > > $x = $attributeReflection->newInstance() as ?MyAttribute; > if ($x === null) // do something since the attribute isn't MyAttribute > > > I think reusing nullability for this would be a

Re: [PHP-DEV] Proposal: AS assertions

Hi Rowan On Tue, Mar 19, 2024 at 8:39 PM Rowan Tommins [IMSoP] wrote: > > As well pattern matching, which Ilija mentioned, another adjacent feature is > a richer set of casting operators. Currently, we can assert that something is > an int; or we can force it to be an int; but we can't easily s

Re: [PHP-DEV] Proposal: AS assertions

On 19/03/2024 16:24, Robert Landers wrote: $x = $attributeReflection->newInstance() as ?MyAttribute; if ($x === null) // do something since the attribute isn't MyAttribute I think reusing nullability for this would be a mistake - ideally, the right-hand side should allow any type, so "$foo as

Re: [PHP-DEV] Proposal: AS assertions

Hi Marco On Tue, Mar 19, 2024 at 7:04 PM Marco Aurélio Deleu wrote: > > > On 19 Mar 2024, at 14:51, Ilija Tovilo wrote: > > > > Hi Robert > > > >> On Tue, Mar 19, 2024 at 5:24 PM Robert Landers > >> wrote: > >> > > See https://wiki.php.net/rfc/pattern-matching#throwing_alternative. I > > beli

Re: [PHP-DEV] Proposal: AS assertions

Marco Deleu > On 19 Mar 2024, at 14:51, Ilija Tovilo wrote: > > Hi Robert > >> On Tue, Mar 19, 2024 at 5:24 PM Robert Landers >> wrote: >> >> I've been thinking about this as an RFC for awhile, but with generics >> being far off (if at all), I'd like to propose a useful idea: reusing >>

Re: [PHP-DEV] Proposal: AS assertions

On Tue, 19 Mar 2024 at 17:46, Deleu wrote: > On Tue, Mar 19, 2024 at 1:42 PM Marco Pivetta wrote: > >> One note: if what you are going for is what `azjezz/psl`, be aware that >> exception / error tracing design needs special attention here: it's not as >> simple as it looks! >> > > I believe you

Re: [PHP-DEV] Proposal: AS assertions

Hi Robert On Tue, Mar 19, 2024 at 5:24 PM Robert Landers wrote: > > I've been thinking about this as an RFC for awhile, but with generics > being far off (if at all), I'd like to propose a useful idea: reusing > the AS keyword in a different context. > > Example: > > $x = $attributeReflection->ne

Re: [PHP-DEV] Proposal: AS assertions

On Tue, Mar 19, 2024 at 1:42 PM Marco Pivetta wrote: > One note: if what you are going for is what `azjezz/psl`, be aware that > exception / error tracing design needs special attention here: it's not as > simple as it looks! > I believe you answered your own question here. The proposal seems fa

Re: [PHP-DEV] Proposal: AS assertions

Hey Robert, On Tue, 19 Mar 2024 at 17:24, Robert Landers wrote: > Hello internals, > > I've been thinking about this as an RFC for awhile, but with generics > being far off (if at all), I'd like to propose a useful idea: reusing > the AS keyword in a different context. > > Example: > > $x = $at

[PHP-DEV] Proposal: AS assertions

Hello internals, I've been thinking about this as an RFC for awhile, but with generics being far off (if at all), I'd like to propose a useful idea: reusing the AS keyword in a different context. Example: $x = $attributeReflection->newInstance() as MyAttribute; This would essentially perform th

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On 18/03/2024 04:39, Alexander Pravdin wrote: I'm not in the context of the core team plans regarding "strict types". Could you share some details here? What is the current plan regarding it? To make strict types on by default eventually? Or something else? PHP doesn't really have a defined "c

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

Sorry for the so late reply, but I would like to continue the discussion on this topic. On Tue, Dec 12, 2023 at 10:04 PM G. P. B. wrote: >> I didn't know that the strict types directive was a mistake. My intention is >> to be able to write clean all-decimal units of code and not break the >>

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

> There's been discussion recently about how to deal with incompatibilities > between different PDO drivers, especially now that we can have subclasses per > driver. That may be the way to deal with it. I don't have a major opinion > on the approach, other than all incompatibilities should be

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

On Tue, Feb 6, 2024, at 2:28 PM, Saki Takamachi wrote: > Hi Larry, > >> I like this proposal. It's a good incremental improvement to PDO. I also >> agree with rollbackTo(), to avoid confusion. > > Thank you, I'm glad to receive your positive feedback. > > It is very difficult to implement these

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

Hi Larry, > I like this proposal. It's a good incremental improvement to PDO. I also > agree with rollbackTo(), to avoid confusion. Thank you, I'm glad to receive your positive feedback. It is very difficult to implement these in pdo_odbc because the odbc API does not support savepoint. How

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

On Mon, Feb 5, 2024, at 1:54 PM, Saki Takamachi wrote: > Hi Kentaro, > > Thank you for your important point. > >> While most databases use `SAVEPOINT [name]`, but: >> >> https://github.com/laravel/framework/blob/v10.43.0/src/Illuminate/Database/Query/Grammars/SqlServerGrammar.php#L453-L456 >> >>

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

Hi Kentaro, Thank you for your important point. > While most databases use `SAVEPOINT [name]`, but: > > https://github.com/laravel/framework/blob/v10.43.0/src/Illuminate/Database/Query/Grammars/SqlServerGrammar.php#L453-L456 > > ```php > return 'SAVE TRANSACTION '.$name; > ``` > > SQL Server u

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

Hi Saki, Aside from a few concerns, I think your proposal is very sensible. I have long felt a disconnect that while we have `beginTransaction()`, `commit()`, and `rollback()` methods, there's no equivalent functionality for `SAVEPOINT` in PDO. It seems natural to support these commonly used tran

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

Hi Kamil, > Why does this have to be done in PHP? Why can this not be done in SQL? Of course, we can also do it with SQL. Indeed, many frameworks do that. However, if we think about it from that perspective, functions such as `beginTransaction()` and `commit()` can also be executed with SQL, ex

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

Hi Saki, Why does this have to be done in PHP? Why can this not be done in SQL? Also, I am not sure that mysqli implements this properly. It's probably not the best extension to take an example of. Regards, Kamil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: ht

[PHP-DEV] [Proposal] Add `savepoint()` method to PDO

Hi internals, I'm thinking of adding a `savepoint(string $name)` method to PDO. Similarly, add `releaseSavepoint(string $name)` and change the signature of `rollback()` to `rollback(?string $name = null)`. Savepoint is a feature defined in SQL99, so it is a feature supported by many databases.

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Fri, Dec 15, 2023 at 12:59 PM Arvids Godjuks wrote: > > > On Fri, 15 Dec 2023 at 22:32, Jordan LeDoux > wrote: > >> On Fri, Dec 15, 2023 at 12:14 AM Robert Landers > > >> wrote: >> >> > >> > nobody will likely ever try this again, at least in the foreseeable >> > future. With comments like th

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Fri, 15 Dec 2023 at 22:32, Jordan LeDoux wrote: > On Fri, Dec 15, 2023 at 12:14 AM Robert Landers > wrote: > > > > > nobody will likely ever try this again, at least in the foreseeable > > future. With comments like that, there is simply no way forward. > > There's no convincing (at least via

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Fri, Dec 15, 2023 at 12:14 AM Robert Landers wrote: > > nobody will likely ever try this again, at least in the foreseeable > future. With comments like that, there is simply no way forward. > There's no convincing (at least via email) and by that point, it's too > late anyway, they already vo

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Fri, Dec 15, 2023 at 2:10 AM G. P. B. wrote: > > On Tue, 12 Dec 2023 at 21:00, Robert Landers wrote: >> >> On Tue, Dec 12, 2023 at 2:04 PM G. P. B. wrote: >> > GMP supports operator overloading >> >> GMP kinda-sorta-most-of-the-time supports operator overloading. >> Sometimes ... it doesn't.

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Wed, 13 Dec 2023 at 09:29, Alexander Pravdin wrote: > On Wed, Dec 13, 2023 at 6:11 PM Robert Landers > wrote: > > I just ran `apt install php8.3-decimal` and tried this: > > > > $a = new Decimal\Decimal("1", 2); > > $b = $a + $a; > > PHP Warning: Uncaught TypeError: Unsupported operand types

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Tue, 12 Dec 2023 at 21:00, Robert Landers wrote: > On Tue, Dec 12, 2023 at 2:04 PM G. P. B. wrote: > > GMP supports operator overloading > > GMP kinda-sorta-most-of-the-time supports operator overloading. > Sometimes ... it doesn't. I implemented a field library in PHP (for > work a couple of

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Wed, Dec 13, 2023 at 6:11 PM Robert Landers wrote: I just ran `apt install php8.3-decimal` and tried this: > > $a = new Decimal\Decimal("1", 2); > $b = $a + $a; > PHP Warning: Uncaught TypeError: Unsupported operand types: > Decimal\Decimal + Decimal\Decimal in > > So, it appears not. > I've

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Wed, Dec 13, 2023 at 9:37 AM Stephen Reay wrote: > > > > > On 7 Dec 2023, at 13:36, Alex Pravdin wrote: > > > > Hello internals, > > > > > > This is the second round of the discussion regarding arbitrary precision > > scalar type integration into PHP. The previous part: > > https://marc.info

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

> On 7 Dec 2023, at 13:36, Alex Pravdin wrote: > > Hello internals, > > > This is the second round of the discussion regarding arbitrary precision > scalar type integration into PHP. The previous part: > https://marc.info/?l=php-internals&m=168250492216838&w=2 was initiated by me > before

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Tue, Dec 12, 2023 at 4:29 PM Jordan LeDoux wrote: > > > On Tue, Dec 12, 2023 at 3:05 PM Erick de Azevedo Lima < > ericklima.c...@gmail.com> wrote: > >> Oh, I just realized that I used the wrong word, so let me rephrase that: >> >> What's the name of the library you're talking about? Maybe the

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

On Tue, Dec 12, 2023 at 3:05 PM Erick de Azevedo Lima < ericklima.c...@gmail.com> wrote: > Oh, I just realized that I used the wrong word, so let me rephrase that: > > What's the name of the library you're talking about? Maybe the *pros* of a > core implementation can be highlighted if we can see

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

Oh, I just realized that I used the wrong word, so let me rephrase that: What's the name of the library you're talking about? Maybe the *pros* of a core implementation can be highlighted if we can see the limitations of a user-land approach. Best, Erick Em ter., 12 de dez. de 2023 às 18:52, Eric

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

Hi Jordan. What's the name of the library you're talking about? Maybe the cons of a core implementation can be highlighted if we can see the limitations of a user-land approach. Best, Erick Em ter., 12 de dez. de 2023 às 18:35, Jordan LeDoux escreveu: > On Tue, Dec 12, 2023 at 1:26 PM Larry Ga

  1   2   3   4   5   6   7   8   9   10   >