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
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 d
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 do
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
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 ord
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
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
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
On 03/09/2015 04:26 PM, Rowan Collins wrote:
On 9 March 2015 09:43:32 GMT, Shawn McCool wrote:
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, r
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
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
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/uns
On 9 March 2015 09:43:32 GMT, Shawn McCool wrote:
>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
> Someone got an idea ?
Simply arrows, without word "this"
number = $number;
}
public function original() {
return $->number;
}
public function addTo($amount) {
return $->number + $amount;
}
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
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
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 w
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
On Mon, Mar 9, 2015 at 3:31 PM, Kalle Sommer Nielsen wrote:
> Hi
>
> 2015-03-09 15:
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
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 recomm
I guess that if I thought that PHP would change its scoping, I would have
tried for that.
On Mon, Mar 9, 2015 at 3:11 PM, Mike Dugan wrote:
> 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
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?
On Mon, Mar 9, 2015 at 2:48 PM, Mike Dugan wrote:
> Shawn & Stellan,
>
> (Apologies if this gets delivered twice, had to confirm myself o
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 nothi
Hi,
On 9 March 2015 at 17:43, Shawn McCool wrote:
> 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 ==
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
On Monday, March 9, 2015, Shawn McCool wrote:
> I've never submitte
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 M
25 matches
Mail list logo
