On Fri, Nov 12, 2021 at 5:08 AM Nikita Popov wrote:
>
> Hi internals,
>
> I've opened the vote on
> https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> 2021-11-26.
>
> Regards,
> Nikita
In the Motivation section when talking about static analysis the RFC
makes the claim:
>
On Tue, Nov 16, 2021 at 5:55 PM Larry Garfield
wrote:
> 1. If we adopt the RFC right now as-is, the market has ~12 months to add
> the attribute. If we instead have a default-true flag that changes to
> default false in the future, it means at minimum 24 months in which to add
> the attribute to
> Le 17 nov. 2021 à 00:56, Larry Garfield a écrit :
>
> They'll get a deprecation, but... we're shouting from the rooftops that
> deprecations shouldn't be a big red warning, so if you want a big red warning
> you can't get that until PHP 9.
Deprecation notices *are* big red warnings. They
Thank you Sara!
I could not agree more with you. I think this answers to most tweets and
messages that I’ve seen the past few weeks.
// Tobias
> On 16 Nov 2021, at 14:20, Sara Golemon wrote:
>
> Serious questions for all the folks worried that this is some kind of death
> nail for PHP.
>
> 1
On Tue, Nov 16, 2021, at 4:10 PM, Sara Golemon wrote:
> On Mon, Nov 15, 2021 at 11:21 AM Larry Garfield
> wrote:
>
>> A possible idea to help make this transition (which I do support) more
>> gradual:
>>
>> Instead of an "allow" attribute, introduce a boolean flag attribute.
>>
>> #[DynamicPropert
On Nov 16, 2021, at 14:02, Kamil Tekiela wrote:
> When used with a name of a function, it will give you the name of that
> function as a string.
Again, this is not true. Names of classes and functions are not resolved the
same way. Consider:
namespace Some\Namespace;
use function Other
On 16 November 2021 23:02:59 CET, Kamil Tekiela wrote:
>Hi Dusk,
>
>Perhaps, you misunderstood me. Take a look at the documentation
>https://www.php.net/manual/en/language.oop5.basic.php#language.oop5.basic.class.class
>::class is just a compile time transformation. It will give you the fully
>qua
Serious questions for all the folks worried that this is some kind of death
nail for PHP.
1. Do you have code you're responsible for which uses dynamic properties so
broadly that adding this attribute is a burden?
2. Do you know of real code in widespread use which uses dynamic properties
so broad
On Mon, Nov 15, 2021 at 11:21 AM Larry Garfield
wrote:
> A possible idea to help make this transition (which I do support) more
> gradual:
>
> Instead of an "allow" attribute, introduce a boolean flag attribute.
>
> #[DynamicProperties(true)]
> class Beep {}
>
> The attribute marks whether dynami
Hi Dusk,
Perhaps, you misunderstood me. Take a look at the documentation
https://www.php.net/manual/en/language.oop5.basic.php#language.oop5.basic.class.class
::class is just a compile time transformation. It will give you the fully
qualified name of *something* as a string literal. The only excep
On Nov 16, 2021, at 10:56, Kamil Tekiela wrote:
> Ok, but a popular usage is also with functions. For example, strlen::class.
> What should the compiler use in this case?
Popular in what context?
I'm not sure this usage is even correct. strlen::class isn't the name of the
strlen function; it's
> Le 16 nov. 2021 à 18:34, Kamil Tekiela a écrit :
>
>
> At the moment, ::class is just a preprocessor macro. It is not part of the
> runtime.
This is not true in general. For example `static::class` is not resolvable at
compile-time.
(In fact, many years ago, when I played with that new f
Ok, but a popular usage is also with functions. For example, strlen::class.
What should the compiler use in this case?
Replacing a string with an object of a strigable class is not the same. Say
I have code like this:
function callFoo(callable $func) {
echo $func('bar');
}
callFoo(strlen::clas
Maybe I'm missing something but now that you said it's kind of a macro, I think
it would actually be pretty easy to implement, at least when not taking
backwards compatibility or performance into account:
class ClassName {
private $name;
function __construct(string $name) {
$this->name =
Interesting, but what would such a type actually be? How would PHP check
the type? What would be the rules?
At the moment, ::class is just a preprocessor macro. It is not part of the
runtime. It also doesn't mean the name of the class. It just means "textual
representation of the value on the left
Hey André,
On Tue, Nov 16, 2021 at 6:22 PM André Hänsel wrote:
> It is common (with DI systems for example) and to my knowledge not
> particularly discouraged to have function parameters that are supposed to
> accept something like Foo::class, which currently is a string.
>
> It seems logical t
It is common (with DI systems for example) and to my knowledge not
particularly discouraged to have function parameters that are supposed to
accept something like Foo::class, which currently is a string.
It seems logical to ask for a special type that can hold class names, so
that parameters that
On Tue, Nov 16, 2021, at 7:18 AM, Lynn wrote:
> On Tue, Nov 16, 2021 at 1:23 PM Pierre Joye wrote:
>
>> On Tue, Nov 16, 2021 at 4:11 PM Lynn wrote:
>> > What is the point of this change if it's an opt-in? Projects that are
>> still relying on dynamic properties today and "have no time" to fix the
On Tue, Nov 16, 2021 at 6:00 PM Andreas Heigl wrote:
> Hey list.
> Which performance improvement of the "original state" of the RFC? As
> that was one of the questions that were not 100% answered: What are the
> benefits for the language. And while those 8 bit that Nikita mentioned
> in the
Hey list.
On 16.11.21 16:26, Deleu wrote:
On Tue, Nov 16, 2021 at 3:59 PM James Gilliland wrote:
On Tue, Nov 16, 2021 at 4:23 AM Rowan Tommins
wrote:
On 16/11/2021 09:27, Andreas Heigl wrote:
I see, yes, code that is 100% perfectly tested can get away without
the language performing any
On Tue, Nov 16, 2021 at 3:59 PM James Gilliland wrote:
> On Tue, Nov 16, 2021 at 4:23 AM Rowan Tommins
> wrote:
>
> > On 16/11/2021 09:27, Andreas Heigl wrote:
> > >
> > >> I see, yes, code that is 100% perfectly tested can get away without
> > >> the language performing any error checking at al
On Tue, Nov 16, 2021 at 4:23 AM Rowan Tommins
wrote:
> On 16/11/2021 09:27, Andreas Heigl wrote:
> >
> >> I see, yes, code that is 100% perfectly tested can get away without
> >> the language performing any error checking at all - the behaviour is
> >> all guaranteed by the tests. I would be very
On 16.11.2021 at 14:48, Côme Chilliet wrote:
> GD Support => enabled
> GD Version => bundled (2.1.0 compatible)
> gd.jpeg_ignore_warning => 1 => 1
>
> So it seems the one I built used a bundled older version of GD? How should I
> change my configure line to use the same GD as the other one?
Whil
Le mardi 16 novembre 2021, 13:40:30 CET Christoph M. Becker a écrit :
> On 16.11.2021 at 13:11, Côme Chilliet wrote:
> > I have a difference in behavior between PHP 8.1 RC6 and my system PHP for
> > the function imagettfbbox.
> > It is hard to know if this is a problem with 8.1 really because I ha
On Tue, Nov 16, 2021 at 1:23 PM Pierre Joye wrote:
> On Tue, Nov 16, 2021 at 4:11 PM Lynn wrote:
> > What is the point of this change if it's an opt-in? Projects that are
> still relying on dynamic properties today and "have no time" to fix them
> now, won't have time in 3 years either. Please l
On 16.11.2021 at 13:11, Côme Chilliet wrote:
> I have a difference in behavior between PHP 8.1 RC6 and my system PHP for the
> function imagettfbbox.
> It is hard to know if this is a problem with 8.1 really because I had to
> download and build imagick through pecl to be able to run this.
imag
On Tue, Nov 16, 2021 at 4:11 PM Lynn wrote:
>
>
>
> On Tue, Nov 16, 2021 at 4:52 AM Pierre Joye wrote:
>>
>>
>> My vote will change to yes as soon as the change is an opt-in instead of an
>> opt-out for the 8.x lifetime.
>>
>
> What is the point of this change if it's an opt-in? Projects that are
Hello,
I have a difference in behavior between PHP 8.1 RC6 and my system PHP for the
function imagettfbbox.
It is hard to know if this is a problem with 8.1 really because I had to
download and build imagick through pecl to be able to run this.
int(1)
[1]=>
int(0)
[2]=>
int(8)
[3]=
On 16/11/2021 09:27, Andreas Heigl wrote:
I see, yes, code that is 100% perfectly tested can get away without
the language performing any error checking at all - the behaviour is
all guaranteed by the tests. I would be very surprised if even 1% of
PHP applications can claim such comprehensive
Hi list,
On Tue, 16 Nov 2021, 00:21 Deleu, wrote:
> I see a pattern in these discussions from two mindsets: one thinking about
> how we should design the future and another thinking about how we preserve
> the past.
I would frame that differently as those who
1. Predominantly write new code (m
Hey all
On 16.11.21 10:16, Rowan Tommins wrote:
On 15/11/2021 17:20, Andreas Heigl wrote:
When you are testing whether writing 'X' to a property and then
reading from that property gives that 'X' back, then everything should
be good.
I see, yes, code that is 100% perfectly tested can get
On 15/11/2021 17:20, Andreas Heigl wrote:
When you are testing whether writing 'X' to a property and then
reading from that property gives that 'X' back, then everything should
be good.
I see, yes, code that is 100% perfectly tested can get away without the
language performing any error ch
On Tue, Nov 16, 2021 at 4:52 AM Pierre Joye wrote:
>
> My vote will change to yes as soon as the change is an opt-in instead of an
> opt-out for the 8.x lifetime.
>
>
What is the point of this change if it's an opt-in? Projects that are still
relying on dynamic properties today and "have no time"
On 15/11/2021 18:27, Arvids Godjuks wrote:
If a 3rd party package combines fixing major bugs with a release of a
significant version and including also the new attribute that's available
only on newer PHP version?
Just to be clear, attributes are designed in such a way that you, and
third-par
34 matches
Mail list logo
