> On 24 Jun 2022, at 22:45, Dan Ackroyd wrote:
>
> Larry Garfield wrote:
>
>> "Create all DB sub-classes?" - I'd say they all should have subclasses, even
>> if empty. It's more consistent* that way, and you can then also rely on
>> instanceof giving you useful information rather than
On Fri, Jun 24, 2022, at 11:43 AM, Nicolas Grekas wrote:
>> > Hi everyone
>> >
>> > I'd like to start a discussion on a simple RFC to allow fetching
>> > properties in constant expressions.
>> > https://wiki.php.net/rfc/fetch_property_in_const_expressions
>> >
>> > The RFC proposes adding support
> > Hi everyone
> >
> > I'd like to start a discussion on a simple RFC to allow fetching
> > properties in constant expressions.
> > https://wiki.php.net/rfc/fetch_property_in_const_expressions
> >
> > The RFC proposes adding support for fetching properties in constant
> > expressions using the ->
Hi Guilliam,
> > There are also cases where using "->value" is just not possible. I
> mention
> > attributes in the RFC,
>
> which also mentions
> https://wiki.php.net/rfc/fetch_property_in_const_expressions (but with
> "For people that use non-strict mode, this extra “->value” is
> boilerplate
On Fri, 24 Jun 2022 at 16:38, Dan Ackroyd wrote:
> YAGNI, and I'm lazy. But mostly, I don't think adding them now
> actually helps achieve anything.
>
Fair enough, but as a minimum there should be an internal API for
registering a sub-class, without any modification to ext/pdo.
For instance,
> domain SymfonyPermission: string;
> domain AcmePermission: string { 'admin' | 'user' | 'bot' };
> [...]
> Domains can also be considered sets, which you could compare directly,
> and maybe even calculate intersections, unions, etc:
>
> The actual values would be ordinary strings, and type
Larry Garfield wrote:
> "Create all DB sub-classes?" - I'd say they all should have subclasses, even
> if empty. It's more consistent* that way, and you can then also rely on
> instanceof giving you useful information rather than "well, it's not one of
> the special ones, so beyond that, NFI."
On Fri, 24 Jun 2022 at 15:05, Jeffrey Dafoe wrote:
> A thin wrapper would be the most flexible. Someone can always write a
> "friendlier" class using your thin wrapper, as you mentioned, but one
> cannot easily go the other direction.
>
I think this argument has some validity when talking
On Tue, 21 Jun 2022 at 10:41, Rowan Tommins wrote:
>
> The implementation MUST be written by
> someone with intimate knowledge of the DBMS in question, or it cannot be
> trusted.
Well, that rules me out of doing it.
> So if we only have a Postgres implementation right now, we should either
>
On Tue, 21 Jun 2022 at 02:26, Larry Garfield wrote:
>
> Any chance I could convince you to move away from the DSN for the factory?
No. That sounds like a challenge for someone who knows about (and
cares about) that problem. There's also not enough time to have that
discussion before feature
On Fri, Jun 24, 2022, at 8:49 AM, Pierrick Charron wrote:
> Hi all, and thanks Levi for your feedback,
>
> If you look at the first thread (Discussion about new Curl URL API and
> ext/curl improvements) you'll see that this was my first approach. I even
> proposed to "OOPify" the actual CurlHandle
Please do not add yet another thin wrapper of an underlying C API. PHP is
not a drop-in replacement of C. PHP is a much higher-level language.
Developers should not have to understand how the underlying library works
to be able to use PHP. We need to move away from thin C wrappers as a
language.
Hi
On 6/24/22 15:49, Pierrick Charron wrote:
If you look at the first thread (Discussion about new Curl URL API and
ext/curl improvements) you'll see that this was my first approach. I even
proposed to "OOPify" the actual CurlHandle & co objects with "simple"
methods like $ch->setOpt(). Anyone
Hello Pierrick,
A thin wrapper would be the most flexible. Someone can always write a
"friendlier" class using your thin wrapper, as you mentioned, but one cannot
easily go the other direction.
-Jeff
-Original Message-
From: Pierrick Charron
Sent: Friday, June 24, 2022 9:49 AM
To:
Hi all, and thanks Levi for your feedback,
If you look at the first thread (Discussion about new Curl URL API and
ext/curl improvements) you'll see that this was my first approach. I even
proposed to "OOPify" the actual CurlHandle & co objects with "simple"
methods like $ch->setOpt(). Anyone who
> It would have been interesting to get some more feedback on why people
> voted No - some took part in the discussion, but most didn't.
Indeed... Of those who did, I have retained the following arguments
(sorry in advance for any omission, approximation or
misinterpretation):
- no impact
16 matches
Mail list logo
