On 12/03/2019 21:40, Stanislav Malyshev wrote:
Isn't it just:
trait Locked {
public function __set($name, $value) {
throw new RuntimeException("Property $name not declared!");
}
public function __get($name) {
throw new RuntimeException("Property $name not declared!");
It was already addressed how using such trivial solution is insufficient,
please read whole thread
> On 12. Mar 2019, at 22:40, Stanislav Malyshev wrote:
>
> Hi!
>
>> While it can be useful, the ability to set an object property which is
>> not part of the class definition can also lead to sub
Hi!
> While it can be useful, the ability to set an object property which is
> not part of the class definition can also lead to subtle bugs. Banning
> this for all objects would be a significant and painful breaking change,
> so I propose instead the option to mark a particular class with a new
>
On Mon, 11 Mar 2019 at 12:35, Nikita Popov wrote:
>
> Removing the ability to use dynamic properties (even excluding stdClass)
> is probably not feasible on a short timetime. However, I think that having
> a directory-scoped declare would also be useful for that, because it allows
> a more gradua
On Mon, Mar 11, 2019 at 1:14 PM Rowan Collins
wrote:
> Hi Nikita,
>
> On Mon, 11 Mar 2019 at 11:27, Nikita Popov wrote:
>
> > The solution I would prefer is the ability to declare that within a
> > project, all interactions with objects (whether they are my own or come
> > from 3rd parties) shou
On Mon, 11 Mar 2019 at 12:14, Rowan Collins wrote:
>
> declare(strict_properties=0) {
> class Foo {}
> $foo = new Foo;
> $foo->bar = 42;
> }
> declare(strict_properties=1) {
> echo $foo; # Is $bar now 'defined', or do we only count the properties
> in the original class definition
Hi Nikita,
On Mon, 11 Mar 2019 at 11:27, Nikita Popov wrote:
> The solution I would prefer is the ability to declare that within a
> project, all interactions with objects (whether they are my own or come
> from 3rd parties) should disallow the creation of dynamic properties. This
> differs from
On Sun, Mar 10, 2019 at 7:35 PM Rowan Collins
wrote:
> Hi all,
>
> I'd like to present a new RFC for "locked classes": classes which
> restrict dynamically adding or removing properties from their instances.
>
> While it can be useful, the ability to set an object property which is
> not part of
On 10/03/2019 21:09, Marco Pivetta wrote:
Still feasible though: PRs to
https://github.com/Roave/Dont/tree/master/src/Dont welcome
Indeed. Many things in a language are sugar for something that could be
done in a more complex way; it's a judgement call which ones are worth
including, and may
Still feasible though: PRs to
https://github.com/Roave/Dont/tree/master/src/Dont welcome
On Sun, 10 Mar 2019, 21:56 Rowan Collins, wrote:
> On 10/03/2019 20:19, Dan Ackroyd wrote:
> > trait LockedClass
> > {
> > public function __set($name, $value)
> > {
> > throw new \Exception("Property [$name
On 10/03/2019 20:19, Dan Ackroyd wrote:
trait LockedClass
{
public function __set($name, $value)
{
throw new \Exception("Property [$name] doesn't exist for class [" .
get_class($this) . "] so can't set it");
}
public function __get($name)
{
throw new \Exception("Property [$name] doesn't exist f
On 10/03/2019 20:19, Dan Ackroyd wrote:
I believe those two parts of the RFC are completely possible already
in user-land with a trait similar to the one below. What would be the
compelling case for making it be a keyword, rather than the user-land
implementation that is already achievable?
On 10/03/2019 19:46, Marco Pivetta wrote:
@rowan: I've stated it multiple times in the past, but if the mechanism is
to be removed, then it should be replaced with a language-level concept of
laziness then.
1) I'm all for adding a language-level concept of laziness. It feels
like it could fit
On Sun, 10 Mar 2019 at 18:35, Rowan Collins wrote:
>
> Hi all,
>
> - Attempting to set a property on the instance which was not declared in
> the class (or inherited from one of its parent classes) will throw an
> error, and the instance will not be modified.
> - Attempting to read a property on t
> On Mar 10, 2019, at 13:35, Rowan Collins wrote:
>
> Hi all,
>
> I'd like to present a new RFC for "locked classes": classes which restrict
> dynamically adding or removing properties from their instances.
Nice. This would help enforce at least one element of immutability in userland;
nam
Typical scenario (works for either of the properties - note that typed
properties that aren't nullable and have no default value also behave the
same way):
class Foo {
private int $a;
private $b;
public function __construct() {
unset($this->b);
}
public function __get(s
On 10/03/2019 18:56, Gabriel O wrote:
Isn’t unset() currently only way to remove reference? This part is hence very
problematic.
Hm, that's an interesting case to consider, thanks!
At the moment, the following code breaks the reference between $a->foo
and $bar, but also deletes the entire p
On Sun, Mar 10, 2019, at 1:52 PM, Marco Pivetta wrote:
> Hi Rowan,
>
> Overall good idea, except that I disagree with the `unset()` being
> disabled: that bit is strictly required for lazy-loading purposes, and
> mostly harmless for userland ("normal" people don't do it, libraries do it).
>
> Bes
Hi Marco,
On 10/03/2019 18:51, Marco Pivetta wrote:
Overall good idea, except that I disagree with the `unset()` being
disabled: that bit is strictly required for lazy-loading purposes, and
mostly harmless for userland ("normal" people don't do it, libraries
do it).
To me, the unset() restr
Isn’t unset() currently only way to remove reference? This part is hence very
problematic.
> On 10. Mar 2019, at 19:35, Rowan Collins wrote:
>
> Hi all,
>
> I'd like to present a new RFC for "locked classes": classes which restrict
> dynamically adding or removing properties from their instan
Hi Rowan,
Overall good idea, except that I disagree with the `unset()` being
disabled: that bit is strictly required for lazy-loading purposes, and
mostly harmless for userland ("normal" people don't do it, libraries do it).
Besides that (blocker for me), if this RFC would be enforced in my codin
Hi all,
I'd like to present a new RFC for "locked classes": classes which
restrict dynamically adding or removing properties from their instances.
While it can be useful, the ability to set an object property which is
not part of the class definition can also lead to subtle bugs. Banning
thi
22 matches
Mail list logo
