# Request Feedback for Instance Variable Sugar RFC - Thread: https://externals.io/message/84460 - Original archive: https://news-web.php.net/php.internals/84460 - Started by Shawn McCool on 2015-03-09T09:43:32+00:00 - Messages: 25 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #84460 — Shawn McCool — 2015-03-09T09:43:32+00:00 URL: https://externals.io/message/84460#84460 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 ===== ===== 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 --- ## #84461 — Jacob Bednarz — 2015-03-09T10:52:30+00:00 URL: https://externals.io/message/84460#84461 · In reply to: #84460 Hey Shane, The @ symbol in PHP is currently an error control operator[1]. Does that mean you will be reassigning the error control operator to another character? [1]: http://php.net/manual/en/language.operators.errorcontrol.php > 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 ===== > > > class Addition { > private $number > > public function __construct($number) { > @number = $number; > } > > public function original() { > return @number; > } > > public function addTo($amount) { > return @number + $amount; > } > } > > > ===== 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 --- ## #84462 — reeze — 2015-03-09T10:54:17+00:00 URL: https://externals.io/message/84460#84462 · In reply to: #84460 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 ===== > > > 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. > } > } > > > ===== 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 --- ## #84471 — Stelian Mocanita — 2015-03-09T13:31:40+00:00 URL: https://externals.io/message/84460#84471 · In reply to: #84462 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, > > > > > […] > can > > […] > and > > […] > > This might decrease readability, since we already comfortable with the > syntax $this->something, in my opinion > > > > […] > > > > […] > > this is a BC break. this is the same as constant number + $amount. so this > syntax is not feasible. > > > > […] > > > > -- > Reeze Xia > http://reeze.cn --- ## #84473 — Shawn McCool — 2015-03-09T13:50:58+00:00 URL: https://externals.io/message/84460#84473 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 > > > > > […] > I > > […] > prefix. > > […] > language > > […] > this > > […] > > -- Shawn McCool | Big Name shawn@heybigname.com heybigname.com --- ## #84474 — Shawn McCool — 2015-03-09T14:11:01+00:00 URL: https://externals.io/message/84460#84474 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 McCool | Big Name > shawn@heybigname.com > heybigname.com > > -- Shawn McCool | Big Name shawn@heybigname.com heybigname.com --- ## #84475 — Shawn McCool — 2015-03-09T14:11:31+00:00 URL: https://externals.io/message/84460#84475 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? > > > > > > > […] > > > -- > Shawn McCool | Big Name > shawn@heybigname.com > heybigname.com > > -- Shawn McCool | Big Name shawn@heybigname.com heybigname.com --- ## #84477 — Kalle Sommer Nielsen — 2015-03-09T14:31:23+00:00 URL: https://externals.io/message/84460#84477 · In reply to: #84475 Hi 2015-03-09 15:11 GMT+01:00 Shawn McCool : > I guess that if I thought that PHP would change its scoping, I would have > tried for that. Well take this code into consideration: 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 --- ## #84478 — Stelian Mocanita — 2015-03-09T14:37:46+00:00 URL: https://externals.io/message/84460#84478 · In reply to: #84477 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 : > > […] > > Well take this code into consideration: > 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 --- ## #84481 — Benoit Schildknecht — 2015-03-09T18:28:06+00:00 URL: https://externals.io/message/84460#84481 · In reply to: #84474 Hi, I think your idea is good. Le Mon, 09 Mar 2015 15:11:01 +0100, Shawn McCool 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. --- ## #84482 — Benoit Schildnecht — 2015-03-09T19:20:50+00:00 URL: https://externals.io/message/84460#84482 · In reply to: #84481 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 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. --- ## #84484 — S.A.N — 2015-03-09T20:27:13+00:00 URL: https://externals.io/message/84460#84484 · In reply to: #84482 > Someone got an idea ? Simply arrows, without word "this" number = $number; } public function original() { return $->number; } public function addTo($amount) { return $->number + $amount; } } --- ## #84487 — Johannes Ott — 2015-03-09T21:02:34+00:00 URL: https://externals.io/message/84460#84487 · In reply to: #84484 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 --- ## #84485 — Rowan Collins — 2015-03-09T21:26:54+00:00 URL: https://externals.io/message/84460#84485 · In reply to: #84460 >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] --- ## #84488 — Stanislav Malyshev — 2015-03-09T22:02:00+00:00 URL: https://externals.io/message/84460#84488 · In reply to: #84485 Hi! > > […] > > 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 --- ## #84489 — Stanislav Malyshev — 2015-03-09T22:38:29+00:00 URL: https://externals.io/message/84460#84489 · In reply to: #84487 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 --- ## #84496 — Larry Garfield — 2015-03-10T03:24:54+00:00 URL: https://externals.io/message/84460#84496 · In reply to: #84485 > > > > […] > 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 --- ## #84520 — Johannes Ott — 2015-03-10T20:46:45+00:00 URL: https://externals.io/message/84460#84520 · In reply to: #84489 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 --- ## #84541 — Rowan Collins — 2015-03-11T13:03:14+00:00 URL: https://externals.io/message/84460#84541 · In reply to: #84520 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] --- ## #84543 — Johannes Ott — 2015-03-11T13:36:54+00:00 URL: https://externals.io/message/84460#84543 · In reply to: #84541 Am 11.03.2015 um 14:03 schrieb Rowan Collins: > Johannes Ott wrote on 10/03/2015 20:46: > > […] > > 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. > > […] > > 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 --- ## #84554 — Rowan Collins — 2015-03-11T16:21:18+00:00 URL: https://externals.io/message/84460#84554 · In reply to: #84543 Johannes Ott wrote on 11/03/2015 13:36: > Am 11.03.2015 um 14:03 schrieb Rowan Collins: > > […] > 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. > > […] > 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] --- ## #84558 — Johannes Ott — 2015-03-11T16:46:25+00:00 URL: https://externals.io/message/84460#84558 · In reply to: #84554 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 --- ## #84560 — Rowan Collins — 2015-03-11T17:12:23+00:00 URL: https://externals.io/message/84460#84560 · In reply to: #84558 Johannes Ott wrote on 11/03/2015 16:46: > Am 11.03.2015 um 17:21 schrieb Rowan Collins: > > > […] > 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; } > > […] > 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'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. > > […] > 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] --- ## #84582 — Johannes Ott — 2015-03-11T21:43:26+00:00 URL: https://externals.io/message/84460#84582 · In reply to: #84560 Am 11.03.2015 um 18:12 schrieb Rowan Collins: > Johannes Ott wrote on 11/03/2015 16:46: > > […] > > 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. > > > […] > > By "somewhere else", I meant "somewhere other than the local scope", so > we're both saying the same thing here. > > > > […] > > 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 --- ## #84933 — Stanislav Malyshev — 2015-03-15T21:56:16+00:00 URL: https://externals.io/message/84460#84933 · In reply to: #84543 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