I am back into PHP internals.
After reading again and again, I would like to say that I think we
should keep the release process as it is. If there is a feature not
currently available in the current release, *at least* a user has
the possibility to download and compile the code by itself;
> On Oct 11, 2022, at 8:24 AM, Christian Schneider
> wrote:
>
> We seem to have two different views on experimental feature here: You are
> saying they could get removed again while others stated it is for stuff which
> will definitely end up in stable when the next major release is done.
>
> On 11 Oct 2022, at 15:24, Christian Schneider wrote:
>
> We seem to have two different views on experimental feature here: You are
> saying they could get removed again while others stated it is for stuff which
> will definitely end up in stable when the next major release is done.
An
Am 11.10.2022 um 07:09 schrieb MKS Archive :
>> On Oct 10, 2022, at 8:04 PM, David Gebler wrote:
>>
>> This is what's bothering me. Either these "experimental" features have
>> passed RFC and will be part of the language, as you've said above, or
>> they're actually experimental i.e. not
Hi all,
I'm still not convinced everyone on this thread is actually talking
about the same idea.
For instance, on whether an experimental feature would require the same
consensus as a non-experimental one:
On 11/10/2022 00:06, Mike Schinkel wrote:
If there were an RFC for Experimental
> On Oct 10, 2022, at 8:04 PM, David Gebler wrote:
>
> This is what's bothering me. Either these "experimental" features have
> passed RFC and will be part of the language, as you've said above, or
> they're actually experimental i.e. not finalized and implementing behaviour
> and syntax
On Mon, Oct 10, 2022 at 5:05 PM David Gebler wrote:
> On Tue, Oct 11, 2022 at 12:05 AM David Rodrigues
> wrote:
>
> > The idea is that the experimental features are exclusively something that
> > the PHP team has voted for (approved) and that will be part of the
> language.
> >
>
> So they're
On Tue, Oct 11, 2022 at 12:05 AM David Rodrigues
wrote:
> The idea is that the experimental features are exclusively something that
> the PHP team has voted for (approved) and that will be part of the language.
>
So they're not experimental features, they're accepted RFCs, maybe with a
lower
> On Oct 10, 2022, at 6:20 PM, David Gebler wrote:
>
> My two cents...
>
> Why can't "common users" install a PECL extension? It's not a difficult,
> obscure or undocumented process.
A lot of developers (most?) who build PHP applications run them in
shared-hosted or managed hosted servers
The idea is that the experimental features are exclusively something that
the PHP team has voted for (approved) and that will be part of the language.
Users can choose to install PECL, but it is not the same, because it
depends on other users (who can make use of this code) having the notion
that
My two cents...
Why can't "common users" install a PECL extension? It's not a difficult,
obscure or undocumented process.
I can accept the reasoning
> Apply a PECL strategy to try experimental features might not be the
convenient way always, for example, if we create a new ... sensitive ini
On 07/10/2022 16:44, Larry Garfield wrote:
Would they have been marked experimental at all? Why?
What might have changed and when while in experimental phase?
When would they have been removed instead of being adjusted?
Etc.
That's an interesting thought experiment. Here are the thoughts
> On 7 Oct 2022, at 18:44, Larry Garfield wrote:
>
> On Fri, Oct 7, 2022, at 5:58 AM, G. P. B. wrote:
>> On Fri, 7 Oct 2022 at 07:57, Christian Schneider
>> wrote:
>>
>>> But now to my main point: You are talking about the most simple and
>>> isolated case, a new function.
>>>
>>
>> I
On Fri, Oct 7, 2022, at 5:58 AM, G. P. B. wrote:
> On Fri, 7 Oct 2022 at 07:57, Christian Schneider
> wrote:
>
>> But now to my main point: You are talking about the most simple and
>> isolated case, a new function.
>>
>
> I agree, and for most intent and purposes a function can be polyfilled in
On Fri, 7 Oct 2022 at 07:57, Christian Schneider
wrote:
> But now to my main point: You are talking about the most simple and
> isolated case, a new function.
>
I agree, and for most intent and purposes a function can be polyfilled in
userland. So this is the least interesting case.
However, I
Am 06.10.2022 um 23:40 schrieb David Rodrigues :
> But keep in mind that these features are already intended for PHP, and it
> is not a "feature test" or suggestion. The voting process is mandatory and
> the feature must already be set to "accepted".
Just so I understand what you are saying: You
> If I start coding an application that relies on these new types, is there
a chance that they'll be removed completely, and I have to rewrite it all?
Imagine that there are users, like me, who would like to test features in
development (mainly in order to provide feedback to the development
On Thu, Oct 6, 2022 at 1:12 PM Rowan Tommins
wrote:
> On 06/10/2022 17:41, Alex Wells wrote:
> > For example, Kotlin has recently introduced a new feature - unsigned
> integer types.
>
>
> I'm still struggling to understand what I, as a user, would do about this.
>
> If I start coding an
> On 6 Oct 2022, at 23:12, Rowan Tommins wrote:
>
> On 06/10/2022 17:41, Alex Wells wrote:
>> For example, Kotlin has recently introduced a new feature - unsigned integer
>> types.
>
>
> I'm still struggling to understand what I, as a user, would do about this.
>
> If I start coding an
On 06/10/2022 17:41, Alex Wells wrote:
For example, Kotlin has recently introduced a new feature - unsigned integer
types.
I'm still struggling to understand what I, as a user, would do about this.
If I start coding an application that relies on these new types, is
there a chance that
> On 6 Oct 2022, at 16:06, Rowan Tommins wrote:
>
> On 06/10/2022 12:16, Alex Wells wrote:
>> A marker merely just tells the compiler "hey, allow me to use this feature
>> right here", i.e. it denotes a piece of code as allowed to use the feature,
>> not enable it. Effectively, all
On 06/10/2022 12:16, Alex Wells wrote:
A marker merely just tells the compiler "hey, allow me to use this feature right here",
i.e. it denotes a piece of code as allowed to use the feature, not enable it. Effectively, all
experimental features are just regular features that are "always on" and
> On 6 Oct 2022, at 15:26, Christoph M. Becker wrote:
>
> On 04.10.2022 at 22:42, David Rodrigues wrote:
>
>> I wanted to suggest the possibility of introducing experimental features to
>> PHP.
>>
>> This is an old thread I guess, but I think it's good to reevaluate the
>> situation from
> On 5 Oct 2022, at 20:41, Rowan Tommins wrote:
>
> On Wed, 5 Oct 2022 at 18:07, David Rodrigues wrote:
>
>> Another advantage in this sense is that it would be possible to have a
>> single development branch for PHP 8.1 (current version) and 8.2
>> (development version), for example, with
On Wed, 5 Oct 2022 at 18:07, David Rodrigues wrote:
> Another advantage in this sense is that it would be possible to have a
> single development branch for PHP 8.1 (current version) and 8.2
> (development version), for example, with the difference of some definitions
> in the code that activate
Thank you all for participating in this discussion!
Regarding the experimental features "disappearing" in a release, therefore,
its use is not reliable, in reality the idea is that this is the exception
of the exception (when, for example, the feature itself proves to be
extremely unfeasible for
Am 05.10.2022 um 15:38 schrieb Alex Wells :
> Advantages of experimental features over extensions:
> - they allow changes to the parser
> - they are universally supported (by IDE's, parsers etc) because they are
> part of a stable language release, not an unpopular/unknown extension
> - usages of
Hey.
Experimental features have been briefly discussed before in
https://github.com/PHPGenerics/php-generics-rfc/issues/49. I believe this
is a good starting point to understand how it's different to extensions or
otherwise different builds of PHP.
Advantages of experimental features over
On Wed, Oct 5, 2022 at 8:16 AM Deleu wrote:
> On Wed, Oct 5, 2022, 7:54 AM juan carlos morales <
> dev.juan.mora...@gmail.com>
> wrote:
>
> >
> > Apply a PECL strategy to try experimental features might not be the
> > convenient way always, for example, if we create a new ... sensitive
> > ...
On Wed, Oct 5, 2022, 7:54 AM juan carlos morales
wrote:
>
> Apply a PECL strategy to try experimental features might not be the
> convenient way always, for example, if we create a new ... sensitive
> ... ini setting that affects the behavior of PHP somehow, then ...
> maybe applying the PECL
My small contribution to this
First of all, nice you picked "json_validate()" for your example,
thanks for this, somehow, support! :)
Second...
Apply a PECL strategy to try experimental features might not be the
convenient way always, for example, if we create a new ... sensitive
... ini
Hi Flávio and Hans!
> Could this be done through extensions instead of having to develop a new
process/support code?
I believe it is possible, however, the main part of the idea would be that
"common users" could try out the features without having to know how to
install extensions, while there
sounds like that's been done with PECL previously yeah?
PECL json until native json_encode in PHP5.2.0,
PECL PDO until native PDO in PHP 5.1.0,
PECL ZendOpcache until native opcache in PHP 5.5.5
etc?
On Wed, 5 Oct 2022 at 00:38, Flávio Heleno wrote:
>
> On Tue, Oct 4, 2022, 17:43 David Rodrigues
On Tue, Oct 4, 2022, 17:43 David Rodrigues wrote:
> I wanted to suggest the possibility of introducing experimental features to
> PHP.
>
> This is an old thread I guess, but I think it's good to reevaluate the
> situation from time to time, as other languages already do this to some
> extent and
34 matches
Mail list logo
