Morning all,
I'd be very up for that ...
The "alternative workflow" in this document seems reasonable for us to use
(or modify for use):
https://wiki.debian.org/Creating%20signed%20GitHub%20releases
RE vendor lock-in: Any provider we may move to in the future is going to
have to be based on
> On Apr 27, 2021, at 18:58, David Gebler wrote:
>
> Anyway, yeah - I've said my piece(s) and I'm not a voting member so what I
> think doesn't matter to that end. I hope my input on internals discussions
> is not entirely moot, though; just like everyone else I take part because
> I'm very fond
Hi,
There is the SQLGetConnectAttr method and the SQL_ATTR_AUTOCOMMIT attribute
(part of the ISO 92 standard) which should allow detecting the transaction
state at the driver level. This API used by the SQL Server extensions (to
manage the transaction) and it also seems to be available for Oracle
Okay, I promise I'll make this my last word on the thread, for the sake of
my own sanity and at this point, I'm sure that of others - first, I really
appreciate your explanation there for why you consider this RFC a good
thing, so thank you for that. Personally, my objections still stand for in
On Tue, Apr 27, 2021 at 7:00 PM Larry Garfield
wrote:
> On Tue, Apr 27, 2021, at 5:48 PM, David Gebler wrote:
> > On Tue, Apr 27, 2021 at 11:23 PM Larry Garfield
> > wrote:
> >
> > The two options to prevent such errors are:
> > >
> > > 1. Sealed classes.
> > > 2. Extend Enums into ADTs.
> > >
> On Apr 27, 2021, at 7:00 PM, Larry Garfield wrote:
>
> On Tue, Apr 27, 2021, at 5:48 PM, David Gebler wrote:
>> On Tue, Apr 27, 2021 at 11:23 PM Larry Garfield
>> wrote:
>>
>> The two options to prevent such errors are:
>>>
>>> 1. Sealed classes.
>>> 2. Extend Enums into ADTs.
>>>
>>
On Tue, Apr 27, 2021, at 5:48 PM, David Gebler wrote:
> On Tue, Apr 27, 2021 at 11:23 PM Larry Garfield
> wrote:
>
> The two options to prevent such errors are:
> >
> > 1. Sealed classes.
> > 2. Extend Enums into ADTs.
> >
>
> Unless I've misunderstood your example, there is a third option
On Tue, Apr 27, 2021 at 11:23 PM Larry Garfield
wrote:
The two options to prevent such errors are:
>
> 1. Sealed classes.
> 2. Extend Enums into ADTs.
>
Unless I've misunderstood your example, there is a third option which quite
possibly prevents the error in a nicer, easier to reason about,
Am 27.04.2021 um 19:19 schrieb Pierre :
> I think that the debate "but if your seal your classes I won't be to extend
> it" is overrated: it's not the language to chose whether or not the
> library/software author can seal its classes or not, it's up the
> library/software author to do its own
On Tue, Apr 27, 2021, at 2:07 PM, Chase Peeler wrote:
> > Sometimes it's helpful to apply a risk perspective the shed some light
> > under hidden assumptions of different arguments. For example, what's
> > the probability and impact of an event that would limit a coder when a
> > library is using
On Tue, Apr 27, 2021 at 12:12 PM David Gebler wrote:
>
>
>
> On Tue, Apr 27, 2021 at 6:56 PM Levi Morrison
> wrote:
>>
>> I think the conversation on final classes being "bad" has gone on long
>> enough. You don't like final, and you don't want to see more features
>> like it being added, such
> On Apr 27, 2021, at 3:07 PM, Chase Peeler wrote:
>
> As someone mentioned above, maybe they want to just add some logging
> capabilities to maybe.
> class MyMaybe extends Maybe {
> protected $logger;
> public function setLogger($logger){ $this->logger = $logger; }
> public function
On Tue, Apr 27, 2021 at 2:57 PM Olle Härstedt
wrote:
> 2021-04-27 20:17 GMT+02:00, Chase Peeler :
> > On Tue, Apr 27, 2021 at 1:56 PM Levi Morrison via internals <
> > internals@lists.php.net> wrote:
> >
> >> I think the conversation on final classes being "bad" has gone on long
> >> enough. You
2021-04-27 20:17 GMT+02:00, Chase Peeler :
> On Tue, Apr 27, 2021 at 1:56 PM Levi Morrison via internals <
> internals@lists.php.net> wrote:
>
>> I think the conversation on final classes being "bad" has gone on long
>> enough. You don't like final, and you don't want to see more features
>> like
Le 27/04/2021 à 19:51, David Gebler a écrit :
I don't think at any moment that any of the
people here really meant that, but it it's fundamentally what this
argument does: it says that some conventions are by nature bad and the
language should enforce people not to write code like this.
I think
On Tue, Apr 27, 2021 at 1:56 PM Levi Morrison via internals <
internals@lists.php.net> wrote:
> I think the conversation on final classes being "bad" has gone on long
> enough. You don't like final, and you don't want to see more features
> like it being added, such as sealed. Point taken. Now
On Tue, Apr 27, 2021 at 6:56 PM Levi Morrison
wrote:
> I think the conversation on final classes being "bad" has gone on long
> enough. You don't like final, and you don't want to see more features
> like it being added, such as sealed. Point taken. Now please stop
> dominating the discussion,
I think the conversation on final classes being "bad" has gone on long
enough. You don't like final, and you don't want to see more features
like it being added, such as sealed. Point taken. Now please stop
dominating the discussion, thank you.
--
PHP Internals - PHP Runtime Development Mailing
On Tue, Apr 27, 2021 at 6:19 PM Pierre wrote:
> Le 27/04/2021 à 18:46, David Gebler a écrit :
> > What's being proposed in the RFC is a functional change to the language
> > whereby attempting to extend a class designated as sealed to a
> > non-specified child results in a fatal error.
>
> It's
Le 27/04/2021 à 18:46, David Gebler a écrit :
What's being proposed in the RFC is a functional change to the language
whereby attempting to extend a class designated as sealed to a
non-specified child results in a fatal error.
It's not a functional change to the language, well, it is a new
On Tue, Apr 27, 2021 at 12:47 PM David Gebler wrote:
> Still, it remains that one could have a legitimate, justifiable reason to
> extend Maybe / some other example, which was not foreseen by its author and
> is prevented by sealed as a keyword despite the fact this inheritance,
> correctly
Still, it remains that one could have a legitimate, justifiable reason to
extend Maybe / some other example, which was not foreseen by its author and
is prevented by sealed as a keyword despite the fact this inheritance,
correctly implemented, would not break anything, not define an impossible
> On Apr 25, 2021, at 15:12, David Rodrigues wrote:
>
> 3. Poorly typed functions or methods cannot be overloaded.
>
> function printId(User $user) { ... }
> function printId($user) { ... } // Fatal error
Since the second is the same as `mixed $user`, why couldn’t the engine
pick the most
On Sat, Apr 24, 2021 at 12:55 PM Saif Eddin Gmati
wrote:
> Hello Internals,
>
> I'm sending this email to open discussion about sealed classes,
> interfaces, and traits feature for PHP 8.1.
>
> I have create a Draft RFC here: https://wiki.php.net/rfc/sealed_classes
>
> A major concern for few
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2021-04-27 at 15:00, b...@benramsey.com wrote:
> > On Apr 27, 2021, at 09:41, Christoph M. Becker
wrote:
> >
> > Hi all,
> >
> > the distributions repo[1] is huge (current ~ 26GiB), and it will grow
> > further over time; that causes issues when
Hi,
On Mon, Apr 26, 2021 at 9:54 AM Christian Schneider
wrote:
> Am 25.04.2021 um 05:47 schrieb Larry Garfield :
> ...
> > sealed class Maybe permits Some, None {
> ...
> > }
> >
> > final class None extends Maybe {}
>
> This is exactly the thing I'm worried about.
>
> Say I want to add
> On Apr 27, 2021, at 09:41, Christoph M. Becker wrote:
>
> Hi all,
>
> the distributions repo[1] is huge (current ~ 26GiB), and it will grow
> further over time; that causes issues when trying to check it out[2],
> and frankly, I don't see why were having the tarballs in a VCS at all.
>
>
Hi all,
the distributions repo[1] is huge (current ~ 26GiB), and it will grow
further over time; that causes issues when trying to check it out[2],
and frankly, I don't see why were having the tarballs in a VCS at all.
Wouldn't it be more suitable to make the tarballs available somewhere
else?
Le 27/04/2021 à 15:21, Dan Ackroyd a écrit :
On Sat, 24 Apr 2021 at 15:03, Benjamin Eberlei wrote:
There is a much less invasive way to add new keywords/flags
to functions by using attributes.
Imho this decouples new features from the language and reduces the "risk"
of adding them to the
On Sat, 24 Apr 2021 at 15:03, Benjamin Eberlei wrote:
>
> There is a much less invasive way to add new keywords/flags
> to functions by using attributes.
>
> Imho this decouples new features from the language and reduces the "risk"
> of adding them to the language.
I think I disagree with this
Le mar. 27 avr. 2021 à 02:04, Ben Ramsey a écrit :
> > On Apr 26, 2021, at 14:47, Sara Golemon wrote:
> >
> > On Mon, Apr 12, 2021 at 2:40 PM Sara Golemon wrote:
> > Please take your newly reset authentication credentials over to
> https://wiki.php.net/todo/php81 and place your ranked votes.
>
On Tue, Apr 27, 2021 at 10:13 AM Stanislav Malyshev
wrote:
> Hi!
>
> On 4/27/21 1:11 AM, Nikita Popov wrote:
> > Author: Nikita Popov (nikic)
> > Date: 2021-04-27T10:10:22+02:00
> >
> > Commit:
> https://github.com/php/php-src/commit/310c0561a9e5ec9a0414654cc96fb2b3c7e1abc7
> > Raw diff:
>
Hi!
On 4/27/21 1:11 AM, Nikita Popov wrote:
Author: Nikita Popov (nikic)
Date: 2021-04-27T10:10:22+02:00
Commit:
https://github.com/php/php-src/commit/310c0561a9e5ec9a0414654cc96fb2b3c7e1abc7
Raw diff:
https://github.com/php/php-src/commit/310c0561a9e5ec9a0414654cc96fb2b3c7e1abc7.diff
Fix
33 matches
Mail list logo
