[PHP-DEV] [RFC] [vote] Support object type in BCMath

Hi all! Voting for RFC: Support object type in BCMath has started. Voting ends on 2024-05-16 00:00 GMT. https://wiki.php.net/rfc/support_object_type_in_bcmath Regards, Saki

Re: [PHP-DEV] PDO subclass names

Hi Arvīds, > I wasn't proposing rolling a separate driver or anything like that, just an > alias that would reserve a namespace for MariaDB and if there's ever a need > to actually roll the driver, that alias be replaced with actual driver. > The thing is at this point MySQL and MariaDB have a

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Alex, > Just one small note from me, for mod operation, related to scale there is a > mention of "Use the scale of the dividend as is". > In reality, I think it should be the same as add and sub, "The larger scale > of the two values is applied". > In this way, something like this can work

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi, If there is no further discussion, I will start voting tomorrow. (I haven't decided on the time yet.) https://wiki.php.net/rfc/support_object_type_in_bcmath Regards, Saki

Re: [PHP-DEV] PDO subclass names

Hi all,On Tue, Apr 23, 2024 at 11:26 AM Stephen Reay <php-li...@koalephant.com> wrote:Sent from my iPhoneOn 23 Apr 2024, at 18:21, Lynn <kja...@gmail.com> wrote:On Tue, Apr 23, 2024 at 10:21 AM Bilge <bi...@scriptfusion.com> wrote:On 21/04/2024 14:00, Saki Takamachi wro

[PHP-DEV] PDO subclass names

Hi internals, Recently I've been working on an RFC regarding object support for BCMath. While working on that, I learned of the following RFC: https://wiki.php.net/rfc/namespaces_in_bundled_extensions If we follow this RFC, is it reasonable to place subclasses of PDO under the namespace "PDO”?

Re: [PHP-DEV] [RFC][Discussion] PDO driver specific parsers

Hi Matteo, > Thanks for the feedback. I will reference this issue as duplicate too in the > RFC. Thanks for the reference to the issue. > I'm certain if we dig deep enough we'll find a few more. Agree. Maybe we can find something other than PostgreSQL. I have read through your RFC. If we

Re: [PHP-DEV] [RFC][Discussion] PDO driver specific parsers

Hi Matteo, > 2024/04/17 21:24、Matteo Beccati のメール: > > Hello everybody, > > I'd like to start a discussion on a new RFC about fixing the default PDO SQL > parser and having (optional) driver-specific parsers. > > https://wiki.php.net/rfc/pdo_driver_specific_parsers > > Thanks GPB and Tom de

Re: [PHP-DEV] Incorrect terminology usage for rounding modes of round()

Hi Gina, > Hello internals, > > While reviewing the PR for the "Adding bcround, bcfloor and bcceil to BCMath" > RFC [1] with the different rounding modes, > I was made aware of the unfortunate wrong terminology usage of > PHP_ROUND_HALF_UP and PHP_ROUND_HALF_DOWN. > > Indeed,

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi internals, I have reflected the discussion up to this point in the RFC. https://wiki.php.net/rfc/support_object_type_in_bcmath However, the point that the argument of `round()` is "precision" has not yet been reflected in the RFC. The argument names of standard's `round()` are also the

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

Hi Gina, > This isn't a BC Break in theory as class names are, for the time being, > case-insensitive. Strictly speaking, this can be considered a BC Break because the string returned by `::class` changes. However, I'm not sure how much of an impact it will have. Regards, Saki

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Rowan, > Yes, I agree there's a dilemma there. > > The extra point in favour of TOWARD_ZERO is that it's more efficient, because > we don't have to over-calculate and round, just pass scale directly to the > implementation. Any other option makes for unnecessary extra calculation in > code

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

Hi, > To an outsider, it looks wild when feedback starts coming in right before the > vote starts. What's even more startling is that there are people with voting > rights who have never participated in the discussion at all, yet have a right > to wordlessly affect the vote's outcome. I

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Rowan, > That's why I mentioned the two different groups of users. The scale and > rounding mode aren't there for group (a), who just want the scale to be > managed automatically; they are there for group (b), who want to guarantee a > particular result has a particular scale. The result of

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

postscript: The `precision` of `round()` can be negative. I'm not sure if this should be called `scale`. Regards. Saki

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Rowan, a). > I propose: > > - The constructor accepts string|int $num only. > > - All operations accept an optional scale and rounding mode. > > - If no rounding mode is provided, the default behaviour is to truncate. This > means that (new BCMath\Number('20'))->div(3, 5) has the same

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Tim, > I don't see a change made, so perhaps I was unclear in what I said. What I > meant was: Please add a full stub example including all the interfaces, > properties, and methods. It's currently split across multiple code blocks and > the interfaces are missing entirely. > > Example: >

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

> - Use precision instead of scale > - The default maximum precision is 20 digits > - The default rounding mode is HALF_UP > - The constructor takes only $num arguments > - The method can optionally specify any precision and any rounding mode when > calculating > - Operators always use only

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi, To be honest, I think it would be much easier to use if we could make it look like this: - Use precision instead of scale - The default maximum precision is 20 digits - The default rounding mode is HALF_UP - The constructor takes only $num arguments - The method can optionally specify any

Re: [PHP-DEV] Native decimal scalar support and object types in BcMath - do we want both?

Hi Jordan, > To me, while being 100x to 1000x more performant at arithmetic is certainly > reason enough on its own, the fact that MPFR (for example) has C > implementations for more complex operations that can be utilized is the real > selling point. The ext-stats extension hasn't been

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

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

Re: [PHP-DEV] Native decimal scalar support and object types in BcMath - do we want both?

Hi Rowan, > Well, that's the original question: are they actually different purposes, > from the point of view of a user? The purpose of both is different from a detailed perspective. Addition of native types and addition of OOP API. But if think about the purpose from a broader perspective,

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: > >

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Tim, >Oh, that's a good idea. Makes sense. I think it would be simpler to prepare an >RFC separate from this RFC, so I'm going to create one right away. Once you >have a certain amount of content, I would be happy if you could check it out >and make corrections if necessary. Once **I**

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Tim, > - The namespace is inconsistently referred to as "BCMath" and "BcMath", > please check the entire RFC to unify the casing. Thanks, I fixed it. > - The full “stub” should probably include an explicit "implements Stringable" > for clarity. Agree. I describe it explicitly during

Re: [PHP-DEV] Native decimal scalar support and object types in BcMath - do we want both?

Hi Rowan, > While I appreciate that that was the original aim, a lot of the discussion at > the moment isn't really about BCMath at all, it's about how to define a > fixed-precision number type. For instance, how to specify precision and > rounding for operations like division. I haven't seen

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

Re: [PHP-DEV] Native decimal scalar support and object types in BcMath - do we want both?

Hi Rowan, >> On 7 April 2024 01:32:29 BST, Jordan LeDoux wrote: >> >> Internals is just volunteers. The people working on BCMath are doing that >> because they want to, the people working on scalar decimal stuff are doing >> that because they want to, and there's no project planning to tell one

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

Hi Tim, > Hi > > On 4/6/24 17:54, Saki Takamachi wrote: >> However, in the example from "RFC: Namespaces in bundled PHP extensions", >> the acronyms are not camelcased. e.g. `FFI\FFI`, `OpenSSL` >> In other words, the RFC can be interpreted a

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

Hi Tim, >> Strictly speaking, namespace is neither a class nor a method, so isn't it >> outside the scope of this RFC? In fact, RFC: Class Naming makes no mention >> of namespace naming conventions at all. I asked this because there was >> mention of namespaces in the `DOM`. >> If I'm not

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

Hi Tim, > I've just written up the follow-up RFC to my previous “Casing of acronyms in > class and method names” thread and I'm officially opening up the discussion > period for it. > > Please find the following links for your convenience: > > RFC:

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Rowan and folks, > While this is an intriguing idea, it only solves a narrow set of use cases. > For instance: > - The class might want different behaviour for different operations; e.g. > Money(42, 'USD') + Money(42, 'USD') should give Money(84, 'USD'); but > Money(42, 'USD') * Money(42,

Re: [PHP-DEV] Native decimal scalar support and object types in BcMath - do we want both?

Hi Barney, > There are currently two proposals being discussed - native decimal scalar > type support and Support object type in BCMath > > I've been getting involved in the discussion for the BCMath proposal, but not > paying as much attention to the native decimal thread. > > But these seem

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

> I'll try to think of some more good ideas, but if you have any suggestions, > please let me know. Regarding `$roundMode`, a possible approach is to clarify the priority of the current eight values, and if they are different, apply the one with the higher priority. With that in mind, the

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

postscript: For example, Ruby's operator overloading is not by design commutative, so in this case it's always possible to prioritize the properties of the left operand, but which can be a bit confusing.

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Tim, Jordan,On Fri, Apr 5, 2024 at 1:00 PM Tim Düsterhus <t...@bastelstu.be> wrote:Hi On 4/5/24 21:42, Saki Takamachi wrote: > The only solution I can think of at the moment is to impose the constraint that > when computing operator overloading, if the operands are both object

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi,On Fri, Apr 5, 2024 at 2:48 AM Tim Düsterhus wrote:Hi Your `Money` example would allow for unsound and/or non-sense behavior, such as:      $fiveEuros = new Money(5, 'EUR');      $tenDollars = new Money(10, 'EUR');      $what = $fiveEuros + $tenDollars; What would you

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Tim, Barney, > Your `Money` example would allow for unsound and/or non-sense behavior, such > as: > > $fiveEuros = new Money(5, 'EUR'); > $tenDollars = new Money(10, 'EUR'); > > $what = $fiveEuros + $tenDollars; > > What would you expect to be in $what? A `BcMath\Number(15)`? > >

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Tim, > Can you please clean up the RFC text? I find the “Updated X/X” bits > confusing, because I'm not sure whether this is what the RFC is going to > propose, or whether this is something that was superseded by the following > discussion. > > The Wiki already provides a version history

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Barney, > Ah ok. Maybe that's the standard way internal classes are written, and we can > consider it generally an error for a child class to override the constructor > without calling `parent::__construct()`. I know tools warn users not to > forget the parent call. Thanks, A fallback

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Barney, Jordan, I would like to thank you all again for discussing this RFC in great detail. I believe that the specification for the `BCMath\Number` class is in very good shape due to the detailed discussions and the great amount of feedback. Now that we have been able to brush up the

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Chris, > Looks very promising! > > The default value for rounding is PHP_ROUND_TOWARD_ZERO. Is this because it > is the same as the BCMath functions for consistency only or do you expect > this to be the most used rounding mode? > I didn't find any discussion about this choice, sorry if I

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi, I added some examples, corrected incorrect explanations, etc. Now that the specifications have been fairly finalized and the RFC has been clarified, I would like everyone to check it out again. https://wiki.php.net/rfc/support_object_type_in_bcmath Regards. Saki

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Jordan, > It looks pretty good. It should probably give specific guidelines on how "no > scale provided" works for addition, subtraction, multiplication, division, > and exponentiation. The section now doesn't make it clear that the returned > scale will behave differently for addition (the

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Barney, Jordan, > Right, if a class is not final but has only final methods (including > constructor) and no protected properties then it allows people to extend it > but not break any encapsulation or (I think) impose any more BC requirements > on the maintainer (unless we care about

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

PS: Yep, this is pretty much Jordan's library idea. Saki

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Jordan, > The issue is that, presumably, this method will be used within the operator > overload portion of the class entry in C. If it is allowed to be overridden, > then this RFC is sort of providing a stealth operator overload to PHP > developers. As much as I am for operator overloads

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Barney, Jordan, > I think that's a sufficiently different data type that it should be a > different class (if required), and probably a separate RFC, and for now it's > better to stay closer to the existing BCMath API. > > Developers should be prepared to accept that an arbitrary precision

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Jordan, Lynn, > Something like the signature for `getNumber()` in this example would be a > decent solution. Operations which have ambiguous scale (of which truly only > div is in the BCMath library) should *require* scale in the method that calls > the calculation, however for consistency

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Another div case: ``` $num = new Number('0.01'); // scale 18 $num2 = new Number('3'); $div = $num->div($num2); $div->getNumber(); // '0.00' scale 18 $div = $num->div($num2, 20); $div->getNumber(); // '0.0033' scale 20 ``` Regards. Saki

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Jordan, > For addition, it absolutely should expand scale like this, unless the > constructor also defines a default rounding type that is used in that > situation. All numbers, while arbitrary, will be finite, so addition will > always be exact and known based on inputs prior to

Re: [PHP-DEV] Allow properties to be defined on interface

Hi Claude, > For information, the question of properties on interfaces is covered by the > currently discussed RFC “Property hooks”: > https://wiki.php.net/rfc/property-hooks I only half-understand that RFC. Thanks for pointing me out. Regards. Saki

[PHP-DEV] Allow properties to be defined on interface

Hi Larry, > This functionality is included in the Property Hooks RFC, which will be going > to a vote just as soon as Ilija finishes polishing up the test suite for it. > (I think he wants to get it into a "commit as soon as the vote passes" state > before we call the vote, even though

Re: [PHP-DEV] Allow properties to be defined on interface

Hi Larry, > This functionality is included in the Property Hooks RFC, which will be going > to a vote just as soon as Ilija finishes polishing up the test suite for it. > (I think he wants to get it into a "commit as soon as the vote passes" state > before we call the vote, even though that's

[PHP-DEV] Allow properties to be defined on interface

Hi internals, With read-only properties, we no longer need to define getter methods when we can take advantage of them. However, there is still one problem here from a convenience standpoint. That is if we use an interface, we still need to define a getter method. This was mentioned by

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Aleksander, > Enums have 'value' and 'name' properties. Although they are kinda special. I overlooked a few things. https://www.php.net/manual/en/class.transliterator.php https://www.php.net/manual/en/class.random-randomizer.php https://www.php.net/manual/en/class.directory.php

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Derick, >> What is the main difference between getting a read-only property with >> `->value` and getting the value using a method? > > Feeling :-) Do we have precedence with other extension's objects > perhaps already? It depends on the extension. Probably some readonly properties exist

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Aleksander, > If you write it as: > > $result = $num->withScale(4)->add($num2); > > it's not an extra line anymore. I also think that withScale() use will be > rare, as we have the scale in constructor. > > I think the intention is more clear here, and I think it applies to all cases >

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Barney, > Do we also need `toFloat` and `toInt` functions? Seems like using explicit > functions will be safer than casting. > > For toInt I'd expect an exception if the value is outside the range of > possible ints. For toFloat it might be nice to have a flag > argument to give the

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Derick, I made one mistake. > In this case, `$result->scale` will be `'5'`. I added this to the RFC. It's `5`, not `'5’`. Regards. Saki

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Aleksander, > Here's another question. > > 1. Since we have withScale(), do we need to inherit the $scale argument from > the functional API? Can't we derive it from the object the method is being > invoked on? > > So, instead, e.g. > > public function add(BcNum|string|int $num, ?int

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Derick, > - You've picked as class name "BcNum". Following > our naming guidelines, that probably should be \BCMath\Num (or > \BC\Num, but that is less descriptive): > > https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#namespaces-in-extensions > > The reason

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi, I wrote in my RFC that it does not support global settings. Regards. Saki

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Larry, > Global mode settings are an anti-pattern in most cases. Please avoid those > whenever possible, as they lead to unpredictable behavior. Yes, that's right. BCMath has an existing global setting, so I was wondering if it was something I could ignore. But that means there's no

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Aleksander, > After reading https://wiki.php.net/rfc/namespaces_in_bundled_extensions again > I see it is a perfect case to apply it. While it's not a must, I think we > should go with BCMath/Number. Thank you, I have read it now. Certainly in this case it makes sense to use "BcMath" as

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Aleksander, > Was BCMath\Number considered instead of BcNum? Yes, that was one of the candidates. However, as far as I know, there are no examples of PHP internal classes having namespaces. Also, if use a namespace, the code will be written as `new Number()`, which is likely to conflict

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Barney, > No, that's not quite what I meant - I meant more like the opposite: > > > ``` > $bcNum = new BcNum('1234567890123456789.23456789'); > echo $bcNum->format(8, '.', ',') // 1,234,567,890,123,456,789.23456789 > ``` > > > Maybe also worth providing a way to specify that all decimals

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Barney, thanks for the points and suggestions! > Is there any reason not to give the BcNum class a public readonly string > `value` property? Would just save a few characters of typing to use value > instead of getValue(). > Also as with the value, any reason not to make the scale a pubic

[PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi internals, I want to start the discussion on the PHP RFC: Support object type in BCMath. https://wiki.php.net/rfc/support_object_type_in_bcmath Regards. Saki

Re: [PHP-DEV] Supporting object types in BCMath

Hi Jordan, > I've done a lot of performance tuning on my arbitrary precision library, and > will simply state for everyone here that I think the amount of development > effort involved in improving performance of the BCMath library is almost > certainly going to see a return on your effort

Re: [PHP-DEV] Supporting object types in BCMath

Hi Jordan, > Using a BCNum inside a loop is the use case, where every loop would result in > memory allocation for a new object, as well as the overhead of the > constructor, etc. > > Granted, only people who REALLY know what they are doing should be doing > this. Though my library which

Re: [PHP-DEV] Supporting object types in BCMath

Hi, I created a prototype, although it's pretty rough. It can overload operators and calculate not only between `BcNum` but also between `BcNum` and `int` or `string`. https://github.com/php/php-src/pull/13741 I compared the execution times. Test code: ```

Re: [PHP-DEV] Supporting object types in BCMath

Hi Barney, > I would suggest if you do this only supporting immutable objects, or at least > making immutable the default, the one with with the simpler name, and > reserving the mutable version specifically for when people want to use > mutability. The strings used with bcmath today are

Re: [PHP-DEV] Re: Supporting object types in BCMath

Hi Niels, > One advantage of a new API is that it could be more efficient than the > current API. > The current API takes input as strings and outputs strings as a result, and > therefore always has to reconstruct the BCMath internal state. > By keeping everything inside an object you could

[PHP-DEV] Re: Supporting object types in BCMath

Hi, After thinking about it, this could be done in userland. I'll try creating a library myself first. Regards. Saki

[PHP-DEV] Supporting object types in BCMath

Hi internals, BCMath currently only has procedural functions. This is a bit unwieldy for some design patterns and I came up with the idea of ​​supporting object types like mysqli. Yet another idea is to also support immutable objects, like DateTime. e.g. ``` $num1 = new BcNum('1.235');

Re: [PHP-DEV] Re: [pdo_dblib] Correct TDS protocol version

When I thought about it, these constants weren't being output to userland. Just include "version=5.0" in th DSN Saki

Re: [PHP-DEV] Re: [pdo_dblib] Correct TDS protocol version

Hi Rob, > Instead of creating a BC break (which will probably affect older, less > maintained libraries the most), why not create new constants and deprecate > the old constants? I see, it makes sense to provide a transition period for users. Would it be a good idea to deprecate it in 8.4 and

[PHP-DEV] Re: [pdo_dblib] Correct TDS protocol version

Hi, I posted this just when the mailing list was having some trouble, so I'll add a reply just in case. Regards. Saki

Re: [PHP-DEV] Re: Release Managers for PHP 8.4

> Notably, at least one of the volunteers must be a "veteran" release manager, > meaning they have participated in at least one release of PHP in the past. > The other may be an additional veteran, or more ideally, someone new to the > RM role (in order to increase our supply of veteran RMs). >

[PHP-DEV] [pdo_dblib] Correct TDS protocol version

Hi internals, There seems to be an error in the handling of pdo_dblib's TDS protocol version, so I'm thinking of fixing these. Through this email, I would like to discuss the appropriate time and method for correction. — For your reference — There are several derivatives of "SQL Server", with

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

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.

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

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,

[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

Re: [PHP-DEV] `PDO::FETCH_CONSTRUCTOR` fetch mode proposal

Hi Frederik > First off, please excuse me if I’ve done something wrong related to the usage > of the mailing list. This all is completely new to me. Welcome to the internal mailing list! I had looked the pull request, and I'm pleased to have received your email promptly. > Thank you, the link

[PHP-DEV] VCS Account Request: saki

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

Re: [PHP-DEV] [RFC] [VOTE] Change the edge case of round()

Hi all, Voting is now closed. As a result of the vote, this RFC was rejected. (7 in favor, 8 against) Therefore, as stated in the RFC, the following pull request will be adopted to fix the bug in `round()`. https://github.com/php/php-src/pull/12268 Thank you for all your votes. Regards.

Re: [PHP-DEV] [PDO] 2 phase commit

Hi, > Do you have any ideas how to handle this case at the core level in the > regard of php lifecycle? I agree with Kentaro on this. This can be said to be a weakness of two-phase commit itself, but I think it should be addressed in userland or user operations. BTW, I said that I was

Re: [PHP-DEV] [PDO] 2 phase commit

Hi Larry, > I have not heard of this functionality before, so I don't know how common it > is. If it's only lightly supported and in different ways, perhaps this is a > use case for the new per-DB subclasses? Many DBs have this functionality, so I was thinking of implementing it in the same

Re: [PHP-DEV] [PDO] 2 phase commit

Hi Jeff, > Would the implementation use the underlying RDBMS two-phase commit? Or would > the proposal be to try to build something at the PDO layer to mimic two-phase > commits? The former seems good, the latter, not so much. When implementing this, if each DB driver's API has a two-phase

Re: [PHP-DEV] [RFC] [VOTE] Adding bcround, bcfloor and bcceil to BCMath

Hi internals, > I started voting on my RFC "Adding bcround, bcfloor and bcceil to BCMath”. > > Voting will end November 30th, 00:00 GMT. Voting has closed, and the addition of bcround, bcfloor, and bcceil to BCMath was unanimously approved (13:0). I will start creating PRs to implement these.

Re: [PHP-DEV] [PDO] I want to unify the behavior when changing the autocommit mode setting while a transaction is open.

Hi Ayesh, > Unfortunately it did not make it to PHP 8.3, but the RFC vote > indicates the trajectory everyone hopes to have in PDO. It was voted > yes unanimously, so there is definitely a preference in majority of us > to iron out the differences, but perhaps in a non-BC way, preferably > making

[PHP-DEV] [PDO] 2 phase commit

Hi internals, For the past few days I've been thinking about whether to make a suggestion to add two-phase commit functionality to pdo. I would like to hear everyone's opinions. About two-phase commit Regular transactions do not guarantee consistency across multiple DBs. For example, if you

Re: [PHP-DEV] [PDO] I want to unify the behavior when changing the autocommit mode setting while a transaction is open.

Hi, > In the latter case, I suppose they would expect the behaviour to be compliant > with the database standards. I may not have had this perspective. And this is a strong basis for explaining that different drivers behave differently. I will continue with the current implementation and

Re: [PHP-DEV] [PDO] I want to unify the behavior when changing the autocommit mode setting while a transaction is open.

Hi Matteo, > PDO's main goal was to make building db drivers easier, and it's not meant to > be a full DB abstraction layer. > > As such, it is not expected that all databases behave the same, especially > for exotic functionality, such as autocommit. As you say, such behavior varies from DB

[PHP-DEV] Re: [PDO] I want to unify the behavior when changing the autocommit mode setting while a transaction is open.

Please ignore the spelling mistakes Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] [PDO] I want to unify the behavior when changing the autocommit mode setting while a transaction is open.

Hi internals, The following code: ``` $db = new PDO(/* omission */, [PDO::ATTR_ATUOCOMMIT => 0]); $db->beginTransaction(); $db->setAttribute(PDO::ATTR_ATUOCOMMIT, 1); ``` The behavior in this case varies depending on the DB driver and is not unified. MySQL, OCI, ODBC, and Firebird currently

  1   2   >