On 18/05/2024 15:00, Robert Landers wrote:
Hello internals,
I've been thinking about having an "internal" attribute that will emit
a warning if called from outside it's left-most namespace.
Hello Robert,
It's worth looking at the prior art on this - the @internal annotation
from PHPDoc, and
Am 18.05.24 um 19:46 schrieb Robert Landers:
On Sat, May 18, 2024 at 7:38 PM Andreas Heigl wrote:
Hey all.
Am 18.05.24 um 16:00 schrieb Robert Landers:
Hello internals,
I've been thinking about having an "internal" attribute that will emit
a warning if called from outside it's left-most
On Sat, May 18, 2024 at 7:58 PM Larry Garfield wrote:
>
> On Sat, May 18, 2024, at 11:06 AM, Andreas Heigl wrote:
> > Hey all.
> >
> > Am 18.05.24 um 16:00 schrieb Robert Landers:
> >> Hello internals,
> >>
> >> I've been thinking about having an "internal" attribute that will emit
> >> a warning
On 18 May 2024 16:25:06 BST, Robert Landers wrote:
>I thought about that too, but in-general, a vendor has the knowledge
>and capability to ensure any two packages work together (like Doctrine
>plugins in your example).
How do they achieve that "knowledge and capability" other than
On Sat, May 18, 2024 at 7:38 PM Andreas Heigl wrote:
>
> Hey all.
>
> Am 18.05.24 um 16:00 schrieb Robert Landers:
> > Hello internals,
> >
> > I've been thinking about having an "internal" attribute that will emit
> > a warning if called from outside it's left-most namespace.
> >
> > It might
On 18 May 2024 17:13:49 BST, Larry Garfield wrote:
>However, that breaks down with readonly properties, which are not allowed to
>have a sentinel. Uninitialized is their sentinel, for better or worse.
Sorry, I don't understand this statement at all. A readonly property can be set
to
On Sat, May 18, 2024, at 11:06 AM, Andreas Heigl wrote:
> Hey all.
>
> Am 18.05.24 um 16:00 schrieb Robert Landers:
>> Hello internals,
>>
>> I've been thinking about having an "internal" attribute that will emit
>> a warning if called from outside it's left-most namespace.
>>
>> It might look
On Sat, May 18, 2024, at 9:40 AM, Rowan Tommins [IMSoP] wrote:
> On 18/05/2024 11:52, Luigi Cardamone wrote:
>> I am already using a solution like the one
>> proposed by Robert: it works but it
>> leaves some doubts since each project
>> can have a different name for NotSet
>
>
> An argument is
Hey all.
Am 18.05.24 um 16:00 schrieb Robert Landers:
Hello internals,
I've been thinking about having an "internal" attribute that will emit
a warning if called from outside it's left-most namespace.
It might look something like this:
namespace MyCompany\PackageA {
#[\Internal] function
On Sat, May 18, 2024 at 5:18 PM Rowan Tommins [IMSoP]
wrote:
>
> On 18/05/2024 15:00, Robert Landers wrote:
>
> I've been thinking about having an "internal" attribute that will emit
> a warning if called from outside it's left-most namespace.
>
>
> I like the general idea, but I don't think
On 18/05/2024 15:00, Robert Landers wrote:
I've been thinking about having an "internal" attribute that will emit
a warning if called from outside it's left-most namespace.
I like the general idea, but I don't think limiting to "left-most
namespace" is the best semantics.
It's very common
On 18/05/2024 11:52, Luigi Cardamone wrote:
I am already using a solution like the one
proposed by Robert: it works but it
leaves some doubts since each project
can have a different name for NotSet
An argument is often made that this is a good thing, in the sense that
"null" and other
Hi Robert,
> Hello internals,
>
> I've been thinking about having an "internal" attribute that will emit
> a warning if called from outside it's left-most namespace.
>
> It might look something like this:
>
> namespace MyCompany\PackageA {
> #[\Internal] function doStuff() {}
> }
>
>
Hello internals,
I've been thinking about having an "internal" attribute that will emit
a warning if called from outside it's left-most namespace.
It might look something like this:
namespace MyCompany\PackageA {
#[\Internal] function doStuff() {}
}
namespace OtherCompany\PackageB {
> I am already using a solution like the one
> proposed by Robert: it works but it leaves some doubts since each project
> can have a different name for NotSet while it seems a general concept of
the language
Hi everyone.
I just thought of some ways to standardize this:
1 - Create an RFC to
On Sat, May 18, 2024 at 12:52 PM Luigi Cardamone
wrote:
>
> Thank you for your feedback.
>
> I am already using a solution like the one
> proposed by Robert: it works but it
> leaves some doubts since each project
> can have a different name for NotSet
> while it seems a general concept of the
>
Thank you for your feedback.
I am already using a solution like the one
proposed by Robert: it works but it
leaves some doubts since each project
can have a different name for NotSet
while it seems a general concept of the
language.
Besides the example I proposed, I think
that there are many
On Fri, May 17, 2024 at 11:43 PM Luigi Cardamone
wrote:
>
> Hello Internals,
> during last PHPDay in Verona I discussed this topic with some of
> you and it was suggested to me to send an email here.
>
> Here is an example to describe my problem. Imagine a simple
> DTO like this:
>
> class MyDTO{
18 matches
Mail list logo
