On Tue, Jun 25, 2024 at 1:56 AM Bilge wrote:
> Hi Alex,
>
> If you wish to implement data objects, what part of the current proposal
> precludes you from doing so?
>
>
None, but they both try to solve the same problem, so it's highly unlikely
that data objects would ever be considered if this RF
Hey Bilge,
I'm not usually a resident of these discussions, but it seems like this RFC
is heading into a wrong direction. Let me explain: as it currently stands,
static properties and methods live separately from instance properties and
methods. That means a couple of limitations, namely: a static
On Fri, Apr 26, 2024 at 11:01 AM Benjamin Außenhofer
wrote:
> After discussing with Mate shortly one reason for adding $since from a PHP
> project POV is that we do show the $since information in the generated
> documentation output.
>
> Integrating with the work in progress to auto generate part
On Wed, Apr 10, 2024 at 4:01 PM Erick de Azevedo Lima <
ericklima.c...@gmail.com> wrote:
> Maybe if such a feedback was given before and it was decided to go for a
> trimmed version of the feature, maybe Ilija/Larry could have had less work
> to implement and test all the variantes they've done. I
On Tue, Feb 6, 2024 at 7:14 PM Larry Garfield
wrote:
> These two samples *are logically identical*, and even have mostly the same
> performance characteristics, and both expose useful data to static
> analyzers. They're just spelled differently. The advantage of the second
> is that it could be
On Tue, Feb 6, 2024 at 5:26 PM Григорий Senior PHP / Разработчик Web <
6562...@gmail.com> wrote:
> Short answer is yes. Glad to see that personally adapted answer.
>
What are those languages specifically?
On Tue, Feb 6, 2024 at 3:58 PM Григорий Senior PHP / Разработчик Web <
6562...@gmail.com> wrote:
> - add non-breakable interface and language construct `raise` to "throw"
> error without collecting trace
> - that error could be any scalar or object, or you can implement new
> interface for them, k
On Fri, Nov 10, 2023 at 1:33 PM Craig Francis
wrote:
> On 10 Nov 2023, at 10:54, Alex Wells wrote:
>
> PHPStan does find them:
> https://phpstan.org/r/38fc1545-2567-49b9-9937-f275dcfff6f5
>
>
>
> It does not:
>
> https://phpstan.org/r/c533ff42-80e4-4309-975
On Fri, Nov 10, 2023 at 12:47 PM Craig Francis
wrote:
> This will start getting Fatal Type Errors in 9.0... and finding these
> "mistakes" is close to impossible (phpstan doesn't find them; psalm
> requires high levels 1-3)
>
PHPStan does find them:
https://phpstan.org/r/38fc1545-2567-49b9-9937-
On Wed, Oct 18, 2023 at 2:37 PM Pierre wrote:
> Le 18/10/2023 à 13:01, Alex Wells a écrit :
> > The community has just now decided on the PHPDoc syntax for generics,
> has
> > just started widely adopting them in packages and has just got
> first-party
> > support
On Tue, Oct 17, 2023 at 10:40 PM Rowan Tommins
wrote:
Using the same syntax for type information that is guaranteed to be true
> (existing run-time checks) and type information that is "advisory only"
> (new checks for optional static analysis) means users can no longer have
> confidence in that
On Mon, Oct 16, 2023 at 5:08 PM Olle Härstedt
wrote:
> Hello internals,
>
> Was there a previous discussion about the pros/cons of adding only the
> syntax needed for generics, but not the functionality? So static
> analyzers could use it, instead of docblocks. I looked at externals.io
> but coul
On Wed, Apr 12, 2023 at 7:31 PM Stanislav Malyshev
wrote:
> If learning a couple of very simple rules is too much for you, maybe you
> are too busy to take on yourself another responsibility such as
> participating in PHP development. Encouraging drive-by commentary is not
> something that is a g
On Wed, Apr 12, 2023 at 6:15 PM Pierre wrote:
> That was my 2 cents about all this. Maybe what the thread creator mean
> is simply that the PHP development process is kind of hidden in this
> list, and it's not that easy to reach or read for people, even when
> using https://externals.io/
Pierr
On Wed, Apr 12, 2023 at 5:16 PM Rowan Tommins
wrote:
> I think "moving to a modern platform" presents a false dichotomy.
>
> Any move needs to be assessed on both the advantages and disadvantages of
> *both* (or all) options, not just what looks new and shiny if we move.
>
> Some starting points
On Wed, Apr 12, 2023 at 5:09 PM Alain D D Williams
wrote:
> * Archives: already done
It is; however, there's no way to categorize it (except for creating even
more mailing lists), tag it, mark as resolved, close it or basically do
anything other than write a message.
> * Not way of editing: j
On Wed, Apr 12, 2023 at 4:57 PM Marco Pivetta wrote:
> FYI: https://externals.io/message/87501#87501
>
> Also: wow, that was 7 years ago?! :O
>
Thanks. I've completely missed this while searching for an alike thread :)
But as you mentioned, it's been 7 years. Many things and people have
changed
Hey.
PHP currently uses internals@lists.php.net for communication. That includes
mostly RFCs (or their votings, or their pre-discussion) and sometimes
questions about the implementation or possible bugs.
While emailing definitely works, it's not the best UX out there. Here are
some immediate flaw
On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote:
> I don't want to use those weird stuff, but I'm
> doing the best I can to replace every single line of old code that has been
> written in an era that "best practices for PHP development" were not what
> you and I know today.
>
I still do not underst
On Mon, Apr 10, 2023 at 3:59 PM Craig Francis
wrote:
> One team of developers I know are still finding these issues well over a
> year later (they also introduce new code that trips it as well); two other
> teams specifically ignore this deprecation (far too many instances to
> "fix"), and one te
On Mon, Feb 27, 2023 at 5:09 PM Clint Priest wrote:
>
> On 2/13/2023 4:13 AM, Arvids Godjuks wrote:
> > Good day dear Internals!
> >
> > I've been following this thread/RFC from its inception to the current
> > moment. I have watched the situation deteriorate and at this point, I
> have
> > major
On Wed, Jan 18, 2023 at 10:09 PM Claude Pache
wrote:
>
>
> Le 18 janv. 2023 à 19:33, Alex Wells a écrit :
>
> Classes and methods is the expected way of implementing standard library
> in an OO language. New APIs (such as the new Random api) use OO instead of
> functions an
On Wed, Jan 18, 2023, 19:57 Claude Pache wrote:
>
>
> > Le 18 janv. 2023 à 18:27, Kamil Tekiela a écrit :
> >
> > Strings should not be incrementable unless they are numeric strings. The
> > current "feature" is more like a bug from xkcd comic.
> https://xkcd.com/1172/
> >
> > But as there is a
> On 12 Oct 2022, at 11:06, Jordan LeDoux wrote:
>
> If a "preview" doesn't allow us to make breaking changes, then what exactly
> is the point? I don't see any benefit at all to this without that.
>
> If the "preview" is *actually* just "put out an RFC in the next patch
> release as soon as i
> 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 exper
> 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 agre
> 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 ab
> 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,
>
> 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 tim
> 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 t
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 extensi
> On 11 Aug 2022, at 22:02, Larry Garfield wrote:
>
> On Thu, Aug 11, 2022, at 1:59 PM, Alex Wells wrote:
>
>>>> Well, pipe operator is another option, but it’s got it’s downsides
>>>> compared to extension methods:
>>>> - it's less v
> On 11 Aug 2022, at 21:58, Larry Garfield wrote:
>
> On Thu, Aug 11, 2022, at 1:51 PM, Alex Wells wrote:
>
>> The pipe operator RFC has actually been mentioned before; the short
>> takeway is: pipe operator works and has a benefit of using existing
>> functio
> On 11 Aug 2022, at 21:42, Larry Garfield wrote:
>
> On Thu, Aug 11, 2022, at 4:03 AM, Alex Wells wrote:
>
>> Besides, I believe working with existing functions is more of a problem
>> than a bonus - because of the naming. You’d have to clutter your code
>>
> On 11 Aug 2022, at 17:25, Christian Schneider wrote:
>
> Am 11.08.2022 um 11:03 schrieb Alex Wells :
>> That’s just a concept. I’d love to bring a lot more examples in an RFC if
>> there’s more positive than negative feedback. Again, I’m more looking for
>&
> On 11 Aug 2022, at 18:10, Rowan Tommins wrote:
>
> On 11/08/2022 10:03, Alex Wells wrote:
>> You could argue the problem is that all of these are single-liners, so here
>> are the same examples, but multiline formatted:
>
>
> When people talk about avoidin
> On 11 Aug 2022, at 07:36, Paul Crovella wrote:
>
> This isn't impossible. There's nothing stopping an IDE from seeing
> `$collection->` and suggesting/completing that with `map($collection, ` -
> they just don't right now. Offhand I don't see why this would be more
> difficult for them to
> On 11 Aug 2022, at 00:30, Rowan Tommins wrote:
>
> a class implementing __call is assumed to reserve *all* method names.
This does make sense. Either an extension has precedence over class methods or
it does not; having extension methods in the middle of statically defined
methods and __cal
Thanks for explaining it better than I did.
Regarding the implementation, that was roughly what I was thinking.
But can't we put extension methods second, after real methods but before
__call? As far as I understand, the reason to put it after __call is to
avoid a performance penalty on __call ca
se, unless you attempt to import both of them in a
scope of one file.
On Wed, Aug 10, 2022 at 7:18 PM Ben Ramsey wrote:
> On 8/10/22 09:17, Alex Wells wrote:
>
> > The idea is to introduce extension methods, similar to those in Kotlin,
> C#,
> > Dart. For those unfamilia
I believe disallowing multiple extensions on one type defeats one of
the purposes of the feature - extending from outside. Let's say you have a
vendor package for manipulating strings which defines an extension on
`string` type. It works, but then you need one more custom extensions -
some kind of
Hey internals.
The idea is to introduce extension methods, similar to those in Kotlin, C#,
Dart. For those unfamiliar, those are just regular functions with fancy
syntax. However, I think having those will not only improve readability,
but also cover some of the previously requested features.
Say
42 matches
Mail list logo
