[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');
$num1imm = new BcNumImmutable('1.235');
$num2 = new BcNum('2.001');
$num1result = $num1->add($num2);
$num1immResult = $num1imm->add($num2);
$num1->getValue(); // '3.236'
$num1result->getValue(); // '3.236'
$num1imm->getValue(); // '1.235'
$num1immResult->getValue(); // '3.236'
```
The reason why the class name is not "BCNum" is because it needs to follow the
current PHP naming convention. As an example, the class name of a PDO subclass
has a name such as "PdoOdbc".
I look forward to your feedback.
Regards.
Saki
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Fri, Mar 15, 2024, at 11:25 PM, Rowan Tommins [IMSoP] wrote:
> On 15 March 2024 17:11:29 GMT, Larry Garfield wrote:
>>On Wed, Mar 13, 2024, at 10:26 PM, Rowan Tommins [IMSoP] wrote:
>>> I think it would be more helpful to justify this design on its own
>>> merits, particularly because it's a significant difference from other
>>> languages (which either don't have a "real property" behind the hooks,
>>> or in Kotlin's case allow access to it only *directly* inside the hook
>>> definitions, via the "field" keyword).
>>
>>I'm not sure I follow. The behavior we have currently is very close to how
>>Kotlin works, from a user perspective.
>
>
> Unless I'm misunderstanding something, the backing field in Kotlin is
> accessible only inside the hooks, nowhere else. I don't know what would
> happen if a hook caused a recursive call to itself, but there's no
> mention in the docs of it bypassing the hooks, only this:
>
>> This backing field can be referenced in the accessors using the `field`
>> identifier
>
> and
>
>> The `field` identifier can only be used in the accessors of the property.
>
> And then a section explaining that more complex hooks should use a
> separate backing property - which is the only option in C#, and roughly
> what people would do in PHP today with __get and __set.
>
> Kotlin does have a special syntax for "delegating" hooks, but looking
> at the examples, they do not use the backing field at all, they have to
> provide their own storage.
>
>
>
>>I've lost track of which specific issue you have an issue with or would want
>>changed. The guards to prevent an infinite loop are necessary, for the same
>>reasons as they are necessary for __get/__set.
>
> I understand that *something* needs to happen if a recursive call
> happens, but it could just be an error, like any other unbounded
> recursion.
>
> I can also understand the temptation to make it something more useful
> than an error, and provide a way to access the "backing field" / "raw
> value" from outside the hook. But it does lead to something quite
> surprising: the same line of code does different things depending on
> how it is called.
>
> I doubt many people have ever discovered that __get and __set work that
> way, since as far as I can see it's only possible to use deliberately
> if you're dynamically adding and unsetting properties inside your class.
>
> So, I don't necessarily think hooks working that way is the wrong
> decision, I just think it's a decision we should make consciously, not
> one that's obvious.
Well, reading/writing from within a set/get hook is an obvious use case to
support. We cannot do cached properties easily otherwise:
public string $expensive {
get => $this->expensive ??= $this->compute();
set {
if (strlen($value) < 50) throw new Exception();
$this->expensive = $value;
}
}
So disabling the hooks from within the hooks seems like the only logical
solution there. (Short of bringing back $field and making it mandatory, which
is actually much harder than it sounds because of the ++ et al operators that
would need to be supported.)
The other case then becomes:
class Foo {
public string $a {
get => $this->expensive ??= $this->compute();
set {
if (strlen($value) < 50) throw new Exception();
$this->expensive = $value;
}
}
public function compute() {
$start = $this->expensive ?? 'a';
return $start . 'b';
}
}
Inside compute(), the logic requires reading from $this->expensive. If we have
no guard, that would cause an infinite loop. If the guard extends down the
call stack, then the loop is eliminated.
That does mean, as you note, that if you call $foo->compute(), the first call
to $this->expensive will invoke the get hook, but subsequent calls to it will
not. That may seem odd, but in practice, we do not see any other alternative
that doesn't make infinite loops very easy to write. This is, of course, a
highly contrived example. In practice, I don't expect it to come up much in
the first place.
It was this logic that led us to the current implementation: Once you're within
the callstack of a hook, you bypass that property's hooks. We then noted that
__get/__set have essentially the same guard logic. It doesn't come up often
because, again as you note, it's only relevant in even more contrived examples.
So yes, the current logic is very deliberate and based on a process of
elimination to arrive at what we feel is the only logical design. Likely the
same process of elimination that led to the behavior of the guards on
__get/__set, which is why they are essentially the same. Being the same also
makes the language more predictable, which is also a design goal for this RFC.
(Hence why "this is the same logic as methods/__get/other very similar thing"
is mentioned several times in the RFC. Consistency in expectations is
generally a good thing.)
In theory we could also forbid accessing a
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On 15 March 2024 17:11:29 GMT, Larry Garfield wrote: >On Wed, Mar 13, 2024, at 10:26 PM, Rowan Tommins [IMSoP] wrote: >> I think it would be more helpful to justify this design on its own >> merits, particularly because it's a significant difference from other >> languages (which either don't have a "real property" behind the hooks, >> or in Kotlin's case allow access to it only *directly* inside the hook >> definitions, via the "field" keyword). > >I'm not sure I follow. The behavior we have currently is very close to how >Kotlin works, from a user perspective. Unless I'm misunderstanding something, the backing field in Kotlin is accessible only inside the hooks, nowhere else. I don't know what would happen if a hook caused a recursive call to itself, but there's no mention in the docs of it bypassing the hooks, only this: > This backing field can be referenced in the accessors using the `field` > identifier and > The `field` identifier can only be used in the accessors of the property. And then a section explaining that more complex hooks should use a separate backing property - which is the only option in C#, and roughly what people would do in PHP today with __get and __set. Kotlin does have a special syntax for "delegating" hooks, but looking at the examples, they do not use the backing field at all, they have to provide their own storage. >I've lost track of which specific issue you have an issue with or would want >changed. The guards to prevent an infinite loop are necessary, for the same >reasons as they are necessary for __get/__set. I understand that *something* needs to happen if a recursive call happens, but it could just be an error, like any other unbounded recursion. I can also understand the temptation to make it something more useful than an error, and provide a way to access the "backing field" / "raw value" from outside the hook. But it does lead to something quite surprising: the same line of code does different things depending on how it is called. I doubt many people have ever discovered that __get and __set work that way, since as far as I can see it's only possible to use deliberately if you're dynamically adding and unsetting properties inside your class. So, I don't necessarily think hooks working that way is the wrong decision, I just think it's a decision we should make consciously, not one that's obvious. Regards, Rowan Tommins [IMSoP]
Re: [PHP-DEV] is this thing on?
On Tue, 5 Mar 2024 at 01:27, wrote: > > > The VSC part from github (hosting our code), can very easily be ported. > > Issues, discussions etc can not. > > > > With the ongoing enshittification of most of the Internet due to > > advertising and tracking, we'd be negligent not hosting and owning our own > > content (including our issue tracker, but that ship has sailed now). > > PHP actually recently moved from a self-hosted VCS to github due to a hack > that compromised php's source code, moving back to a self-hosted instance > seems like a downgrade. > > However, if that's being discussed, it can be done properly, i.e. with a > self-hosted gitlab instance, which also provides issues, projects, CI, > basically the full devops experience, that would be the perfect chance to > also move the mailing list and php wiki to gitlab (which is how many FOSS > projects work currently, I.e. wayland, xorg, mesa, pipewire, asahi use the > gitlab.freedesktop.org gitlab instance, arch linux has its own gitlab > instance (which is also used for RFCs)). > > > > Email has been around for half a century. Will things like Slack, Discord, > > and the like still be operational and allow access to our archives in > > another 25 years? I'm almost certain it won't be. > > No one is proposing to move the issue tracker to discord, slack or telegram: > those are messengers, and should not be used as support forums for such a > major language, mainly because they're non-indexable. > > Regards, > Daniil Gentili > Interesting thing with GitHub discussions, issues and PRs is that they are also like some sort of temporary chat. In my experience whatever we've discussed on PHP GitHub places was never actually very important for the project maintainers nor taken seriously. Mailing list was always a bit more serious and taken with a slight priority. Interesting is that we have discussed something on GitHub but then later people have implemented something completely different or completely forgot about the thing we've discussed on GitHub. I think that GitHub requires a lot of effort to participate. You can't only discuss it from your mobile phone. There actual implementations need to be done. And by all means, GitHub PHP places are all there, waiting for people to jump in and write a word or two where they feel needed.
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Wed, Mar 13, 2024, at 10:26 PM, Rowan Tommins [IMSoP] wrote: > On 12/03/2024 22:43, Larry Garfield wrote: >> It's slightly different, yes. The point is that the special behavior of a >> hook is disabled if you are within the call stack of a hook, just like the >> special behavior of __get/__set is disabled if you are within the call stack >> of __get/__set. What happens when you hit an operation that would otherwise >> go into an infinite loop is a bit different, but the "disable to avoid an >> infinite loop" logic is the same. > > > I guess I'm looking at it more from the user's point of view: it's very > rare with __get and __set to have a method that sometimes accesses the > "real" property, and sometimes goes through the "hook". Either there is > no real property, or the property has private/protected scope, so any > method on the classes sees the "real" property *regardless* of access > via the hook. > > I think it would be more helpful to justify this design on its own > merits, particularly because it's a significant difference from other > languages (which either don't have a "real property" behind the hooks, > or in Kotlin's case allow access to it only *directly* inside the hook > definitions, via the "field" keyword). I'm not sure I follow. The behavior we have currently is very close to how Kotlin works, from a user perspective. (The internal implementation is backwards from Kotlin, but that doesn't matter to the user.) I've lost track of which specific issue you have an issue with or would want changed. The guards to prevent an infinite loop are necessary, for the same reasons as they are necessary for __get/__set. We couldn't use a backing field otherwise, without some other syntax. (This is where Kotlin uses 'field'.) So, I'm not really sure what we're discussing at this point. What specific changes are you suggesting? >> With the change to allow in the absence of set, I believe that would >> already work. >> >> cf: https://3v4l.org/3Gnti/rfc#vrfc.property-hooks > > > Awesome! The RFC should probably highlight this, as it gives a > significant extra option for array properties. Updated. I may try to rewrite the array and references section this weekend, as with the changes in the design to be more permissive I'm not sure it's entirely clear anymore what the net result is. --Larry Garfield
Re: [PHP-DEV] base64_encode without padding
On Fri, Mar 15, 2024 at 9:34 AM Remi Collet wrote: > Le 14/03/2024 à 21:31, Yasuo Ohgaki a écrit : > > > Please add PHP_BASE64_URL flag also. > > This is another feature, out of the scope of this PR > > > Remi > Perhaps you should consider it? Base64 "just without" padding isn't really a standard (that I'm aware of), but url-base64 is and padding is optional. Simply removing padding (in most real-world cases) isn't enough so this flag only gets you part of the way there. So, perhaps adding two flags PHP_BASE64_URL along with this padding flag would be really useful for those of us having to transform a base64 encoded string to a url-base64. Robert Landers Software Engineer Utrecht NL
Re: [PHP-DEV] base64_encode without padding
Le 14/03/2024 à 21:31, Yasuo Ohgaki a écrit : Please add PHP_BASE64_URL flag also. This is another feature, out of the scope of this PR Remi
