Request Feedback for Instance Variable Sugar RFC

11 years ago by Shawn McCool — view source — reply

unread

I've never submitted an RFC. Whether or not you're interested in the
feature, please consider giving me feedback on the RFC itself so that I can
better understand how to succeed in the process.

====== PHP RFC: Instance Variable Sugar ======

Version: 0.1
Date: 2015-03-09
Author: Shawn McCool, shawn@heybigname.com
Status: In Discussion

===== Summary =====

In order to access instance variables, one must use the $this-> prefix.
The problem with this is that it reduces expressiveness in the language and
increases the amount of unnecessary decoration, reducing readability.

This RFC proposes a single character syntax sugar form of $this->.
Instead, an @ can be used to reference instance variables.

The @ replaces the normal $ variable prefix.

===== Example =====

<file php MyClass.php> <?php class Addition { private $number

public function __construct($number) {
@number = $number;
}

public function original() {
return @number;
}

public function addTo($amount) {
return @number + $amount;
}
}
</file>

===== Backwards Compatibility =====

Leave $this-> available.

===== Proposed PHP Version(s) =====

This is proposed for the next PHP x, currently PHP 7.

--
Shawn McCool | Big Name
shawn@heybigname.com
heybigname.com

11 years ago by Jacob Bednarz — view source — reply

unread

Hey Shane,
The @ symbol in PHP is currently an error control operator1. Does that
mean you will be reassigning the error control operator to another
character?

I've never submitted an RFC. Whether or not you're interested in the
feature, please consider giving me feedback on the RFC itself so that I can
better understand how to succeed in the process.

====== PHP RFC: Instance Variable Sugar ======

Version: 0.1

Date: 2015-03-09

Author: Shawn McCool, shawn@heybigname.com javascript:;

Status: In Discussion

===== Summary =====

In order to access instance variables, one must use the $this-> prefix.
The problem with this is that it reduces expressiveness in the language and
increases the amount of unnecessary decoration, reducing readability.

This RFC proposes a single character syntax sugar form of $this->.
Instead, an @ can be used to reference instance variables.

The @ replaces the normal $ variable prefix.

===== Example =====
<file php MyClass.php> <?php class Addition { private $number
public function __construct($number) {
@number = $number;
}

public function original() {
return @number;
}

public function addTo($amount) {
return @number + $amount;
}
}
</file>

===== Backwards Compatibility =====

Leave $this-> available.

===== Proposed PHP Version(s) =====

This is proposed for the next PHP x, currently PHP 7.

--
Shawn McCool | Big Name
shawn@heybigname.com javascript:;
heybigname.com

11 years ago by reeze — view source — reply

unread

Hi,

I've never submitted an RFC. Whether or not you're interested in the
feature, please consider giving me feedback on the RFC itself so that I can
better understand how to succeed in the process.

====== PHP RFC: Instance Variable Sugar ======

Version: 0.1

Date: 2015-03-09

Author: Shawn McCool, shawn@heybigname.com

Status: In Discussion

===== Summary =====

In order to access instance variables, one must use the $this-> prefix.
The problem with this is that it reduces expressiveness in the language and
increases the amount of unnecessary decoration, reducing readability.

This might decrease readability, since we already comfortable with the
syntax $this->something, in my opinion

This RFC proposes a single character syntax sugar form of $this->.
Instead, an @ can be used to reference instance variables.

The @ replaces the normal $ variable prefix.

===== Example =====
<file php MyClass.php> <?php class Addition { private $number
public function __construct($number) {
@number = $number;
}

public function original() {
return @number;
}

public function addTo($amount) {
return @number + $amount;

this is a BC break. this is the same as constant number + $amount. so this
syntax is not feasible.

}
}
</file>

===== Backwards Compatibility =====

Leave $this-> available.

===== Proposed PHP Version(s) =====

This is proposed for the next PHP x, currently PHP 7.

--
Shawn McCool | Big Name
shawn@heybigname.com
heybigname.com

--
Reeze Xia
http://reeze.cn

11 years ago by Stelian Mocanita — view source — reply

unread

Hi Shawn,

My opinion is that even though the "@" operator should be deprecated in
further along the line removed, it should not be repurposed for anything,
it has too much legacy imho.

While a shortcut might be a good idea, I personally favour the $this->var
syntax just for muscle memory if nothing else.

Stelian

Hi,

I've never submitted an RFC. Whether or not you're interested in the
feature, please consider giving me feedback on the RFC itself so that I
can
better understand how to succeed in the process.

====== PHP RFC: Instance Variable Sugar ======

Version: 0.1

Date: 2015-03-09

Author: Shawn McCool, shawn@heybigname.com

Status: In Discussion

===== Summary =====

In order to access instance variables, one must use the $this-> prefix.
The problem with this is that it reduces expressiveness in the language
and
increases the amount of unnecessary decoration, reducing readability.

This might decrease readability, since we already comfortable with the
syntax $this->something, in my opinion

This RFC proposes a single character syntax sugar form of $this->.
Instead, an @ can be used to reference instance variables.

The @ replaces the normal $ variable prefix.

===== Example =====
<file php MyClass.php> <?php class Addition { private $number
public function __construct($number) {
@number = $number;
}

public function original() {
return @number;
}

public function addTo($amount) {
return @number + $amount;

this is a BC break. this is the same as constant number + $amount. so this
syntax is not feasible.

}
}
</file>

===== Backwards Compatibility =====

Leave $this-> available.

===== Proposed PHP Version(s) =====

This is proposed for the next PHP x, currently PHP 7.

--
Shawn McCool | Big Name
shawn@heybigname.com
heybigname.com

--
Reeze Xia
http://reeze.cn

11 years ago by Rowan Collins — view source — reply

unread

In order to access instance variables, one must use the $this->
prefix.
The problem with this is that it reduces expressiveness in the language
and
increases the amount of unnecessary decoration, reducing readability.

I disagree with this premise. The $this here is not just decorative syntax, it's an actual variable, which can be passed around just like any other variable. The -> is then the standard way of accessing a property or method, applied to that variable.

This is beautifully simple, and expresses what's going on perfectly: if you look at $this->foo, and ask "which foo is being referenced here?", the answer is clearly "the one which is a property of $this".

The only places I can see value in a shorthand are in constructors and setters, where you're just copying from one name to another ($this->foo = $foo). But the part that's redundant there is the variable/property names, not the $this, so what you need is getter/setter support, or shorthand constructors (you should be able to find previous RFCs for both).

Regards,

Rowan Collins
[IMSoP]

11 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

The problem with this is that it reduces expressiveness in the
language and increases the amount of unnecessary decoration,
reducing readability.

I disagree with this premise. The $this here is not just decorative
syntax, it's an actual variable, which can be passed around just like
any other variable. The -> is then the standard way of accessing a
property or method, applied to that variable.

Completely agree. The problem with going to far with overly "expressive"
code - i.e. one that uses as little characters as possible - is that it
becomes less and less comprehensible. $this-> is not too long to be any
real problem (and if it's really that troublesome one always can code a
macro in their editor). It is abundantly clear to both novice and
seasoned programmer. It is a subclass of wider standard syntax (-> as
member access). It has shared pattern for properties and methods, so you
don't need to keep too many concepts in your mind to parse it. I don't
think saving half-dozen characters is worth sacrificing all that.

Stas Malyshev
smalyshev@gmail.com

11 years ago by Larry Garfield — view source — reply

unread

In order to access instance variables, one must use the $this->
prefix.
The problem with this is that it reduces expressiveness in the language
and
increases the amount of unnecessary decoration, reducing readability.
I disagree with this premise. The $this here is not just decorative syntax, it's an actual variable, which can be passed around just like any other variable. The -> is then the standard way of accessing a property or method, applied to that variable.

This is beautifully simple, and expresses what's going on perfectly: if you look at $this->foo, and ask "which foo is being referenced here?", the answer is clearly "the one which is a property of $this".

The only places I can see value in a shorthand are in constructors and setters, where you're just copying from one name to another ($this->foo = $foo). But the part that's redundant there is the variable/property names, not the $this, so what you need is getter/setter support, or shorthand constructors (you should be able to find previous RFCs for both).

Regards,

I concur. I don't see much advantage of a short hand in this case, but
I would love to see someone pick up both the property RFC (which implied
short-hand getter/setters) and shorthand constructors. (It's undoubtedly
too late for 7.0, but they'd be great additions for 7.1.)

--Larry Garfield

11 years ago by Shawn McCool — view source — reply

unread

Sure, they should be separated into two equally impossible to pass RFCs.
However, do you see a reasonable alternative way to achieve this type of
improvement?

Shawn & Stellan,

(Apologies if this gets delivered twice, had to confirm myself on the
mailing list again)

Agreed, @ shouldn’t be repurposed as a macro (or anything). That would
lead to a huge amount of confusion for quite a while, but especially during
the early days of 7. I’m also not a fan of declaring the field with dollar
sign prefix but using it with an @ prefix (or any other prefix for that
matter).

These should probably be separated into two separate RFCs -
deprecating/removing @ error suppression, and pending that one being
accepted the @ instance var macro could then be sent along.

--
Mike Dugan
mike@dugan.io
http://dugan.io

Hi Shawn,

My opinion is that even though the "@" operator should be deprecated in
further along the line removed, it should not be repurposed for anything,
it has too much legacy imho.

While a shortcut might be a good idea, I personally favour the $this->var
syntax just for muscle memory if nothing else.

Stelian

Hi,

I've never submitted an RFC. Whether or not you're interested in the
feature, please consider giving me feedback on the RFC itself so that
I
can
better understand how to succeed in the process.

====== PHP RFC: Instance Variable Sugar ======

Version: 0.1

Date: 2015-03-09

Author: Shawn McCool, shawn@heybigname.com

Status: In Discussion

===== Summary =====

In order to access instance variables, one must use the $this->
prefix.
The problem with this is that it reduces expressiveness in the
language
and
increases the amount of unnecessary decoration, reducing readability.

This might decrease readability, since we already comfortable with the
syntax $this->something, in my opinion

This RFC proposes a single character syntax sugar form of $this->.
Instead, an @ can be used to reference instance variables.

The @ replaces the normal $ variable prefix.

===== Example =====
<file php MyClass.php> <?php class Addition { private $number
public function __construct($number) {
@number = $number;
}

public function original() {
return @number;
}

public function addTo($amount) {
return @number + $amount;

this is a BC break. this is the same as constant number + $amount. so
this
syntax is not feasible.

}
}
</file>

===== Backwards Compatibility =====

Leave $this-> available.

===== Proposed PHP Version(s) =====

This is proposed for the next PHP x, currently PHP 7.

--
Shawn McCool | Big Name
shawn@heybigname.com
heybigname.com

--
Reeze Xia
http://reeze.cn

--
Shawn McCool | Big Name
shawn@heybigname.com
heybigname.com

11 years ago by Shawn McCool — view source — reply

unread

There's a cultural disposition against re-purposing a symbol from one major
version to the next. Let's consider that as fact and move on.

If I wanted to provide syntactic sugar to replace a symbol with $this-> so
that our code can become more expressive if we choose to use it, how would
you recommend implementing that?

@ is not going to be a real option. But what about..

:number = $number;

:add(:number, $number);

or some other character?

Sure, they should be separated into two equally impossible to pass RFCs.

Just a suggestion based on what I’ve seen here before :)

However, do you see a reasonable alternative way to achieve this type of
improvement?

I’m not sure if you mean the syntax in general or more specifically the
declare-with-$ / use-with-@ issue I took with it?

--
Mike Dugan
mike@dugan.io
http://dugan.io

Sure, they should be separated into two equally impossible to pass RFCs.
However, do you see a reasonable alternative way to achieve this type of
improvement?

Shawn & Stellan,

(Apologies if this gets delivered twice, had to confirm myself on the
mailing list again)

Agreed, @ shouldn’t be repurposed as a macro (or anything). That would
lead to a huge amount of confusion for quite a while, but especially during
the early days of 7. I’m also not a fan of declaring the field with dollar
sign prefix but using it with an @ prefix (or any other prefix for that
matter).

These should probably be separated into two separate RFCs -
deprecating/removing @ error suppression, and pending that one being
accepted the @ instance var macro could then be sent along.

--
Mike Dugan
mike@dugan.io
http://dugan.io

On March 9, 2015 at 9:32:23 AM, Stelian Mocanita (stelianm@php.net)
wrote:

Hi Shawn,

My opinion is that even though the "@" operator should be deprecated in
further along the line removed, it should not be repurposed for anything,
it has too much legacy imho.

While a shortcut might be a good idea, I personally favour the $this->var
syntax just for muscle memory if nothing else.

Stelian

Hi,

I've never submitted an RFC. Whether or not you're interested in the
feature, please consider giving me feedback on the RFC itself so that
I
can
better understand how to succeed in the process.

====== PHP RFC: Instance Variable Sugar ======

Version: 0.1

Date: 2015-03-09

Author: Shawn McCool, shawn@heybigname.com

Status: In Discussion

===== Summary =====

In order to access instance variables, one must use the $this->
prefix.
The problem with this is that it reduces expressiveness in the
language
and
increases the amount of unnecessary decoration, reducing readability.

This might decrease readability, since we already comfortable with the
syntax $this->something, in my opinion

This RFC proposes a single character syntax sugar form of $this->.
Instead, an @ can be used to reference instance variables.

The @ replaces the normal $ variable prefix.

===== Example =====
<file php MyClass.php> <?php class Addition { private $number
public function __construct($number) {
@number = $number;
}

public function original() {
return @number;
}

public function addTo($amount) {
return @number + $amount;

this is a BC break. this is the same as constant number + $amount. so
this
syntax is not feasible.

}
}
</file>

===== Backwards Compatibility =====

Leave $this-> available.

===== Proposed PHP Version(s) =====

This is proposed for the next PHP x, currently PHP 7.

--
Shawn McCool | Big Name
shawn@heybigname.com
heybigname.com

--
Reeze Xia
http://reeze.cn

--
Shawn McCool | Big Name
shawn@heybigname.com
heybigname.com

--
Shawn McCool | Big Name
shawn@heybigname.com
heybigname.com

11 years ago by Benoit Schildknecht — view source — reply

unread

Hi,

I think your idea is good.

Le Mon, 09 Mar 2015 15:11:01 +0100, Shawn McCool shawn@heybigname.com a
écrit:

There's a cultural disposition against re-purposing a symbol from one
major
version to the next. Let's consider that as fact and move on.

If I wanted to provide syntactic sugar to replace a symbol with $this->
so
that our code can become more expressive if we choose to use it, how
would
you recommend implementing that?

@ is not going to be a real option. But what about..

:number = $number;

:add(:number, $number);

or some other character?

: is already used for ternary expression, it will confuse people as well
as softwares and parsing scripts. The RFC would certainly be rejected in
the voting phase.

I would recommend using § or £. I don't think they are actually used, and
they are quite easy to remember.

Regards.

11 years ago by Benoit Schildnecht — view source — reply

unread

Mike Dugan just told me § and £ aren't standard symbols, and he is right, I
didn't have a picture of a standard keyboard when I proposed these symbols
:(

I don't know what could be used instead. Certainly a combination of symbols,
but I can't find one.

Someone got an idea ?

Regards.

""Benoit Schildknecht"" a écrit dans le message de groupe de discussion :
op.xu8tk4pkhuszwh@tsukapiou...

Hi,

I think your idea is good.

Le Mon, 09 Mar 2015 15:11:01 +0100, Shawn McCool shawn@heybigname.com a
écrit:

There's a cultural disposition against re-purposing a symbol from one
major
version to the next. Let's consider that as fact and move on.

If I wanted to provide syntactic sugar to replace a symbol with $this->
so
that our code can become more expressive if we choose to use it, how
would
you recommend implementing that?

@ is not going to be a real option. But what about..

:number = $number;

:add(:number, $number);

or some other character?

: is already used for ternary expression, it will confuse people as well
as softwares and parsing scripts. The RFC would certainly be rejected in
the voting phase.

I would recommend using § or £. I don't think they are actually used, and
they are quite easy to remember.

Regards.

11 years ago by S.A.N — view source — reply

unread

Someone got an idea ?

Simply arrows, without word "this"

<?php
class Addition {
private $number

public function __construct($number) {
$->number = $number;
}

public function original() {
return $->number;
}

public function addTo($amount) {
return $->number + $amount;
}
}

11 years ago by Johannes Ott — view source — reply

unread

Hey

as developing both Java and PHP, I would suggest a solution similar to
Java. As long as there is no conflict to a local variable the keyword
$this should be the default.

Regards

DerOetzi

11 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

as developing both Java and PHP, I would suggest a solution similar to
Java. As long as there is no conflict to a local variable the keyword
$this should be the default.

"As long as" there is a key. There may be conflict, and unlike Java
PHP's properties are dynamic. Java way is very hard to track which
variable belongs where, which is somewhat mitigated by the fact that the
property set is fixed (so the IDE can help you to figure it out) but not
completely. I think PHP's way is more verbose but much more clear.

--
Stas Malyshev
smalyshev@gmail.com

11 years ago by Johannes Ott — view source — reply

unread

Hi,

okay indeed the dynamic properties are a problem I didn't think about on
my suggestion. Without the wish to hijack this thread for another
typesafety discussion, I must say again that PHP needs a less dynamic
and more declaratively properties concept in my opinion.

So I would suggest for now to keep the $this variable, but to make it
more similar to other OOP-languages I would suggest to remove the
$-character in front. In my opinion it would fit better to other object
keywords like parent and self as well.

so i would prefer this->... instead of $this->...

Regards

DerOetzi

11 years ago by Rowan Collins — view source — reply

unread

Johannes Ott wrote on 10/03/2015 20:46:

okay indeed the dynamic properties are a problem I didn't think about on
my suggestion. Without the wish to hijack this thread for another
typesafety discussion, I must say again that PHP needs a less dynamic
and more declaratively properties concept in my opinion.

Yes, I think a standard way to say that a particular object has strictly
declared all its properties, and should not allow would be useful.

(Even with that, though, I'd be against guessing that "$foo" meant
"$this->foo"; it just makes code harder to read.)

So I would suggest for now to keep the $this variable, but to make it
more similar to other OOP-languages I would suggest to remove the
$-character in front. In my opinion it would fit better to other object
keywords like parent and self as well.

Other OOP languages only don't have a sigil such as $ in front of this
if they don't have one in front of any variable. Why should $this,
which acts like a normal variable in pretty much every way, drop the $
when every other variable in the language has one?

Note that the syntax of parent and self is different, and is consistent
with static member/method access, or more strictly "scope resolution".
You can't pass parent or self around as variables, only use them to
resolve scopes, so they don't have a $.

That's what sigils are for - making similar things look similar and
distinct things look distinct.

Regards,

Rowan Collins
[IMSoP]

11 years ago by Johannes Ott — view source — reply

unread

Am 11.03.2015 um 14:03 schrieb Rowan Collins:

Johannes Ott wrote on 10/03/2015 20:46:

okay indeed the dynamic properties are a problem I didn't think about on
my suggestion. Without the wish to hijack this thread for another
typesafety discussion, I must say again that PHP needs a less dynamic
and more declaratively properties concept in my opinion.

Yes, I think a standard way to say that a particular object has strictly
declared all its properties, and should not allow would be useful.

(Even with that, though, I'd be against guessing that "$foo" meant
"$this->foo"; it just makes code harder to read.)

I disagree, programming Java beside PHP since about 15 years now,
personally I think always having "this"-keyword, where it is not
necassary in a strict OOP-world, makes the code more unreadable for the
simple fact it is more to read.

So I would suggest for now to keep the $this variable, but to make it
more similar to other OOP-languages I would suggest to remove the
$-character in front. In my opinion it would fit better to other object
keywords like parent and self as well.

Other OOP languages only don't have a sigil such as $ in front of this
if they don't have one in front of any variable. Why should $this,
which acts like a normal variable in pretty much every way, drop the $
when every other variable in the language has one?

Note that the syntax of parent and self is different, and is consistent
with static member/method access, or more strictly "scope resolution".
You can't pass parent or self around as variables, only use them to
resolve scopes, so they don't have a $.

I only agree a bit, because the keyword "this", is what to call a
hybridization, more often used to define the scope of the property or
method you want to use, then used really as a pure variable.

For example:

this->a;
or
this->some_function(...);

just defining the scope as in the current instance is much more used then.

some_function($this);

That's what sigils are for - making similar things look similar and
distinct things look distinct.

Regards,

--
DerOetzi

11 years ago by Rowan Collins — view source — reply

unread

Johannes Ott wrote on 11/03/2015 13:36:

Am 11.03.2015 um 14:03 schrieb Rowan Collins:

Johannes Ott wrote on 10/03/2015 20:46:

okay indeed the dynamic properties are a problem I didn't think about on
my suggestion. Without the wish to hijack this thread for another
typesafety discussion, I must say again that PHP needs a less dynamic
and more declaratively properties concept in my opinion.
Yes, I think a standard way to say that a particular object has strictly
declared all its properties, and should not allow would be useful.

(Even with that, though, I'd be against guessing that "$foo" meant
"$this->foo"; it just makes code harder to read.)

I disagree, programming Java beside PHP since about 15 years now,
personally I think always having "this"-keyword, where it is not
necassary in a strict OOP-world, makes the code more unreadable for the
simple fact it is more to read.

My reasoning is that code that is ambiguous is hard to read. If "$foo"
can mean either "a local variable called $foo" or "a property of the
current object called $foo", then you have to know which it is in order
to understand what code is doing.

This is not about "a strict OOP-world", incidentally, it's about scoping
rules. Java imports object properties into the scope of each method, PHP
does not. Even if properties had to be declared (which is probably a
good idea), local variables still wouldn't be - in Java, the fact that
it's not declared locally means it must be coming from somewhere else.

I also know that when I was first learning Java at school, it confused
me immensely which variables I was allowed to access in static contexts.
In PHP, that's simple - if you can't access $this, you can't access any
of it's properties.

So I would suggest for now to keep the $this variable, but to make it
more similar to other OOP-languages I would suggest to remove the
$-character in front. In my opinion it would fit better to other object
keywords like parent and self as well.
Other OOP languages only don't have a sigil such as $ in front of this
if they don't have one in front of any variable. Why should $this,
which acts like a normal variable in pretty much every way, drop the $
when every other variable in the language has one?

Note that the syntax of parent and self is different, and is consistent
with static member/method access, or more strictly "scope resolution".
You can't pass parent or self around as variables, only use them to
resolve scopes, so they don't have a $.

I only agree a bit, because the keyword "this", is what to call a
hybridization, more often used to define the scope of the property or
method you want to use, then used really as a pure variable.

For example:

this->a;
or
this->some_function(...);

just defining the scope as in the current instance is much more used then.

some_function($this);

This is true of any object variable.

These resolve the scope of the property/method to the variable $foo:

$a = $foo->a;
$foo->some_function(...);

These resolve the scope of the property/method to the variable $this:

$a = $this->a;
$this->some_function(...);

If you want to resolve the scope of a method to the current object
without using the variable $this, you can also use the "static" keyword;
these are equivalent:

$this->some_function(...);
static::some_function(...);
// http://3v4l.org/E0XYs

There is nothing unvariable-like about $this, so if variables begin with
$, $this should begin with $.

Regards,

Rowan Collins
[IMSoP]

11 years ago by Johannes Ott — view source — reply

unread

Am 11.03.2015 um 17:21 schrieb Rowan Collins:

My reasoning is that code that is ambiguous is hard to read. If "$foo"
can mean either "a local variable called $foo" or "a property of the
current object called $foo", then you have to know which it is in order
to understand what code is doing.

So for clean code rules you should do smaller methods if you can't even
see clearly whether you declared $foo locally or not.

This is not about "a strict OOP-world", incidentally, it's about scoping
rules. Java imports object properties into the scope of each method, PHP
does not. Even if properties had to be declared (which is probably a
good idea), local variables still wouldn't be - in Java, the fact that
it's not declared locally means it must be coming from somewhere else.

No if it is not declared locally it doesn't mean it's coming from
somewhere else, but it means it is coming from one of the next higher
scopes which is normally the Object.

I also know that when I was first learning Java at school, it confused
me immensely which variables I was allowed to access in static contexts.
In PHP, that's simple - if you can't access $this, you can't access any
of it's properties.

I'm not talking about beginners code, but about professional clean code.
If you're doing as a beginner you can still use the $this keyword to
make it clearer code for you to understand. But if you want to do huge
applications you should have understand the difference between static
and non-static context. And if it would be defined well in PHP, modern
IDEs should be able to help you to do no mistakes.

This is true of any object variable.

These resolve the scope of the property/method to the variable $foo:

$a = $foo->a;
$foo->some_function(...);

These resolve the scope of the property/method to the variable $this:

$a = $this->a;
$this->some_function(...);

Okay I agree with this point.

If you want to resolve the scope of a method to the current object
without using the variable $this, you can also use the "static" keyword;
these are equivalent:

$this->some_function(...);
static::some_function(...);
// http://3v4l.org/E0XYs

I don't care whether I use $this-> or static:: as keyword. In this case
I would even prefer $this-> because static in instance context is in my
opinion really confusing.

There is nothing unvariable-like about $this, so if variables begin with
$, $this should begin with $.

Regards,

Regards

--
DerOetzi

11 years ago by Rowan Collins — view source — reply

unread

Johannes Ott wrote on 11/03/2015 16:46:

Am 11.03.2015 um 17:21 schrieb Rowan Collins:

My reasoning is that code that is ambiguous is hard to read. If "$foo"
can mean either "a local variable called $foo" or "a property of the
current object called $foo", then you have to know which it is in order
to understand what code is doing.
So for clean code rules you should do smaller methods if you can't even
see clearly whether you declared $foo locally or not.

True, but again, PHP doesn't give you a way of declaring that a variable
is local, so it would be impossible in isolation to tell if $rate in
this example is a property or just a temporary variable:

public function setRatePercentage($rate_percent) {
$rate = $rate / 100;
$processed_amount = $amount * $rate;
}

This is not about "a strict OOP-world", incidentally, it's about scoping
rules. Java imports object properties into the scope of each method, PHP
does not. Even if properties had to be declared (which is probably a
good idea), local variables still wouldn't be - in Java, the fact that
it's not declared locally means it must be coming from somewhere else.

No if it is not declared locally it doesn't mean it's coming from
somewhere else, but it means it is coming from one of the next higher
scopes which is normally the Object.

By "somewhere else", I meant "somewhere other than the local scope", so
we're both saying the same thing here.

I also know that when I was first learning Java at school, it confused
me immensely which variables I was allowed to access in static contexts.
In PHP, that's simple - if you can't access $this, you can't access any
of it's properties.

I'm not talking about beginners code, but about professional clean code.
If you're doing as a beginner you can still use the $this keyword to
make it clearer code for you to understand.

A lot of beginners start by reading other people's code, or get jobs
working alongside experts. Having completely different styles of
programming for experts and beginners harms collaboration.

It is often observed that code is read much more often than it is written.

If you want to resolve the scope of a method to the current object
without using the variable $this, you can also use the "static" keyword;
these are equivalent:

$this->some_function(...);
static::some_function(...);
// http://3v4l.org/E0XYs
I don't care whether I use $this-> or static:: as keyword. In this case
I would even prefer $this-> because static in instance context is in my
opinion really confusing.

I agree, I was just demonstrating that we already have a keyword syntax,
for scope resolution, as well as a well-behaved variable, $this.

Regards,

Rowan Collins
[IMSoP]

11 years ago by Johannes Ott — view source — reply

unread

Am 11.03.2015 um 18:12 schrieb Rowan Collins:

Johannes Ott wrote on 11/03/2015 16:46:

Am 11.03.2015 um 17:21 schrieb Rowan Collins:

My reasoning is that code that is ambiguous is hard to read. If "$foo"
can mean either "a local variable called $foo" or "a property of the
current object called $foo", then you have to know which it is in order
to understand what code is doing.
So for clean code rules you should do smaller methods if you can't even
see clearly whether you declared $foo locally or not.

True, but again, PHP doesn't give you a way of declaring that a variable
is local, so it would be impossible in isolation to tell if $rate in
this example is a property or just a temporary variable:

public function setRatePercentage($rate_percent) {
$rate = $rate / 100;
$processed_amount = $amount * $rate;
}

As I said before I totaly agree for current state of PHP that with
dynamic properties without declaration inside any scope we need a $this
"operator" as mandatory. But in future if maybe we will have
declaration, typesafety etc. I would vote then for a more java like
behavior.

This is not about "a strict OOP-world", incidentally, it's about scoping
rules. Java imports object properties into the scope of each method, PHP
does not. Even if properties had to be declared (which is probably a
good idea), local variables still wouldn't be - in Java, the fact that
it's not declared locally means it must be coming from somewhere else.

No if it is not declared locally it doesn't mean it's coming from
somewhere else, but it means it is coming from one of the next higher
scopes which is normally the Object.

By "somewhere else", I meant "somewhere other than the local scope", so
we're both saying the same thing here.

I also know that when I was first learning Java at school, it confused
me immensely which variables I was allowed to access in static contexts.
In PHP, that's simple - if you can't access $this, you can't access any
of it's properties.

I'm not talking about beginners code, but about professional clean code.
If you're doing as a beginner you can still use the $this keyword to
make it clearer code for you to understand.

A lot of beginners start by reading other people's code, or get jobs
working alongside experts. Having completely different styles of
programming for experts and beginners harms collaboration.

Yes I agree, but the beginners have to learn to read and understand and
later on to write the expert code, that is no point for me to polute
code with "unnecessary" snippets, because it will make it much harder to
maintain then for everyone. And the best collaboration is to ask the
experts to teach yourself.

It is often observed that code is read much more often than it is written.

This argument really is a point for me. Because if you have lot of
optional-keywords you have more to read and in worst case even to scroll
horizontal.

But I think we should come back to the topic of this thread, I would say
that we should keep $this like it is for the moment, because of some
other lecks in scope and variable concept of PHP.

And I don't see the need of a shortcut-symbol for $this-> because that
really makes the code much harder to read then the keyword "this" do.

Regards

DerOetzi

11 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

necassary in a strict OOP-world, makes the code more unreadable for the
simple fact it is more to read.

R u sre mre 2 rd mns hrdr 2 rd?

--
Stas Malyshev
smalyshev@gmail.com

11 years ago by Shawn McCool — view source — reply

unread

I guess that if I thought that PHP would change its scoping, I would have
tried for that.

Why not use regular variable naming ($foo) and check the object for
accessible instance vars before looking for locally scoped vars? I’ve no
idea how the community would feel about it, but that might be a feasible
approach to getting rid of $this->

--
Mike Dugan
mike@dugan.io
http://dugan.io

On March 9, 2015 at 10:00:03 AM, Shawn McCool (shawn@heybigname.com)
wrote:

There's a cultural disposition against re-purposing a symbol from one
major version to the next. Let's consider that as fact and move on.

If I wanted to provide syntactic sugar to replace a symbol with $this-> so
that our code can become more expressive if we choose to use it, how would
you recommend implementing that?

@ is not going to be a real option. But what about..

:number = $number;

:add(:number, $number);

or some other character?

Sure, they should be separated into two equally impossible to pass
RFCs.

Just a suggestion based on what I’ve seen here before :)

However, do you see a reasonable alternative way to achieve this type of
improvement?

I’m not sure if you mean the syntax in general or more specifically the
declare-with-$ / use-with-@ issue I took with it?

--
Mike Dugan
mike@dugan.io
http://dugan.io

On March 9, 2015 at 9:51:20 AM, Shawn McCool (shawn@heybigname.com)
wrote:

Sure, they should be separated into two equally impossible to pass
RFCs. However, do you see a reasonable alternative way to achieve this type
of improvement?

Shawn & Stellan,

(Apologies if this gets delivered twice, had to confirm myself on the
mailing list again)

Agreed, @ shouldn’t be repurposed as a macro (or anything). That would
lead to a huge amount of confusion for quite a while, but especially during
the early days of 7. I’m also not a fan of declaring the field with dollar
sign prefix but using it with an @ prefix (or any other prefix for that
matter).

These should probably be separated into two separate RFCs -
deprecating/removing @ error suppression, and pending that one being
accepted the @ instance var macro could then be sent along.

--
Mike Dugan
mike@dugan.io
http://dugan.io

On March 9, 2015 at 9:32:23 AM, Stelian Mocanita (stelianm@php.net)
wrote:

Hi Shawn,

My opinion is that even though the "@" operator should be deprecated in
further along the line removed, it should not be repurposed for anything,
it has too much legacy imho.

While a shortcut might be a good idea, I personally favour the $this->var
syntax just for muscle memory if nothing else.

Stelian

Hi,

I've never submitted an RFC. Whether or not you're interested in the
feature, please consider giving me feedback on the RFC itself so
that I
can
better understand how to succeed in the process.

====== PHP RFC: Instance Variable Sugar ======

Version: 0.1

Date: 2015-03-09

Author: Shawn McCool, shawn@heybigname.com

Status: In Discussion

===== Summary =====

In order to access instance variables, one must use the $this->
prefix.
The problem with this is that it reduces expressiveness in the
language
and
increases the amount of unnecessary decoration, reducing readability.

This might decrease readability, since we already comfortable with the
syntax $this->something, in my opinion

This RFC proposes a single character syntax sugar form of $this->.
Instead, an @ can be used to reference instance variables.

The @ replaces the normal $ variable prefix.

===== Example =====
<file php MyClass.php> <?php class Addition { private $number
public function __construct($number) {
@number = $number;
}

public function original() {
return @number;
}

public function addTo($amount) {
return @number + $amount;

this is a BC break. this is the same as constant number + $amount. so
this
syntax is not feasible.

}
}
</file>

===== Backwards Compatibility =====

Leave $this-> available.

===== Proposed PHP Version(s) =====

This is proposed for the next PHP x, currently PHP 7.

--
Shawn McCool | Big Name
shawn@heybigname.com
heybigname.com

--
Reeze Xia
http://reeze.cn

--
Shawn McCool | Big Name
shawn@heybigname.com
heybigname.com

--
Shawn McCool | Big Name
shawn@heybigname.com
heybigname.com

--
Shawn McCool | Big Name
shawn@heybigname.com
heybigname.com

11 years ago by Kalle Sommer Nielsen — view source — reply

unread

Hi

2015-03-09 15:11 GMT+01:00 Shawn McCool shawn@heybigname.com:

I guess that if I thought that PHP would change its scoping, I would have
tried for that.

Well take this code into consideration:
<?php
class A {
protected $b;

function c($b) {
$b = $b; // does not work
}

function d($d) {
$b = $d; // works
}
}
?>

A::c() will fail because the parameter $b conflicts with the property
A::$b, but example works because the parameter is now named $d, and
therefore making $b available for assignment (should probably
internally be implemented as a reference to $this->b), but only on
demand (JIT) to avoid extra memory consumption.

This approach may seem quirky at first, but it doesn't add any new
syntax but some magic behind the scenes. Although I personally am not
a huge fan of magic variables like that, it is possible.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

11 years ago by Stelian Mocanita — view source — reply

unread

On top of the cultural disposition, there is also the fact that things
should not be removed from the language without deprecating them, so at
best 7.0 would emit and E_DEPRECATED for the usage of "@".

Stelian

Hi

2015-03-09 15:11 GMT+01:00 Shawn McCool shawn@heybigname.com:

I guess that if I thought that PHP would change its scoping, I would have
tried for that.

Well take this code into consideration:
<?php
class A {
protected $b;

function c($b) {
$b = $b; // does not work
}

function d($d) {
$b = $d; // works
}
}
?>

A::c() will fail because the parameter $b conflicts with the property
A::$b, but example works because the parameter is now named $d, and
therefore making $b available for assignment (should probably
internally be implemented as a reference to $this->b), but only on
demand (JIT) to avoid extra memory consumption.

This approach may seem quirky at first, but it doesn't add any new
syntax but some magic behind the scenes. Although I personally am not
a huge fan of magic variables like that, it is possible.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Request Feedback for Instance Variable Sugar RFC View as Markdown

Regards,

Regards

Regards,

Regards,

Regards,

Regards