5 ms·

Neat table, one thing about PHP's member variables compared to Python/Ruby seems inaccurate though. In the example "define class", the member variable $value is

by Udo 15y ago

Neat table, one thing about PHP's member variables compared to Python/Ruby seems inaccurate though. In the example "define class", the member variable $value is declared private and then accessed through a getter and a setter, while the corresponding Python and Ruby examples use a public variable and hence look cleaner. The equivalent PHP version should be more along the lines of: class Int { function __construct($int = 0) { $this->value = $int; } } instead of the ridiculously verbose thing they posted there.

msbarnett 15y ago
The Ruby example actually involves generating the getter and setter at runtime via attr_accessor. In contrast to Python, in Ruby all instance member variables are private.
- Udo 15y ago
  Yes, but functionally the Ruby example is the equivalent of a public member variable. Since those are public by default in PHP, there is no need to complicate the code by first making it private and then implementing a getter and a setter.
  - chc 15y ago
    This is a kind of a semantic game. You might say they're "equivalent," but you're still doing different things — and different is very rarely truly equal. For example, the Ruby accessors could be hooked or altered later without changing the interface. Not so if you use a public variable (which Ruby doesn't have, for this very reason). The only language I know of where public variables and accessors are truly interchangeable is Scala.
    - Udo 15y ago
      Everything is a semantics game: meaning matters. This is not about playing "gotcha" with trivialities. I'd like to convince you that there is a significant difference or bias about the way those languages are being showcased. Isn't the whole point of this table to compare equivalent snippets of code? You're right, those languages do things very differently from one another - especially when it comes to OO. In this case, the stated goal was to define a class that exposes a public property. In this I believe PHP and probably Perl were represented badly. If you don't believe me, look at the Python example: it's the exact same implementation I translated into PHP syntax above. So my terse implementation is an exact match for the Python example and it's a functional match for the Ruby example. Hence, I can't help but think that PHP and Perl were misrepresented by making them jump through unnecessary hoops that do nothing but make the language look more complicated.
    - grncdr 15y ago
      I agree with your general point, but feel I should point out that this is possible in python using properties: class Int(object): def __init__(self, value): self.value = value @property def value(self): print("Accessing value") return self.value @value.setter def value(self, value): print("Setting value") self.value = value
grncdr 15y ago
Speaking of ridiculously verbose, if they're going to pull in Moose to do OO in Perl they could at least use it's ability to provide default arguments instead of abusing BUILDARGS: package Int; use Moose; has 'value' => ( is => 'rw', isa => 'Int', default => 0 ); no Moose; Of course, Moose (while awesome) is hardly the only approach to OO in Perl: package Int; sub new { my $cls = shift; $cls = ref($cls) || $cls; my $val = shift or 0; bless \$val, $cls; } sub getValue { ${$_[0]} } 1; Rather than wrapping the scalar int inside another data structure to be treated as an "object" it's possible to just take a reference and use that as our object. So in this case getValue is really just a verbose way to dereference ($int->getValue vs. $$int). If you don't care about inheritance you could also take out the first two lines of ``new`` and just have: package Int; sub new { bless \($_[0] or 0) } sub getValue { ${$_[0]} } 1; Disclaimer: this kind of code is usually considered terrible Perl style and why people have such a hang up about the language, don't take this as idiomatic Edit: Just noticed that they seem to think instance variables in Perl are private by default. Not sure where they got that idea? I guess Moose attributes are read-only by default, but that's hardly the same thing.

by Udo 15y ago

msbarnett 15y ago

The Ruby example actually involves generating the getter and setter at runtime via attr_accessor. In contrast to Python, in Ruby all instance member variables are private.

Udo 15y ago
Yes, but functionally the Ruby example is the equivalent of a public member variable. Since those are public by default in PHP, there is no need to complicate the code by first making it private and then implementing a getter and a setter.
- chc 15y ago
  This is a kind of a semantic game. You might say they're "equivalent," but you're still doing different things — and different is very rarely truly equal. For example, the Ruby accessors could be hooked or altered later without changing the interface. Not so if you use a public variable (which Ruby doesn't have, for this very reason). The only language I know of where public variables and accessors are truly interchangeable is Scala.
  - Udo 15y ago
    Everything is a semantics game: meaning matters. This is not about playing "gotcha" with trivialities. I'd like to convince you that there is a significant difference or bias about the way those languages are being showcased. Isn't the whole point of this table to compare equivalent snippets of code? You're right, those languages do things very differently from one another - especially when it comes to OO. In this case, the stated goal was to define a class that exposes a public property. In this I believe PHP and probably Perl were represented badly. If you don't believe me, look at the Python example: it's the exact same implementation I translated into PHP syntax above. So my terse implementation is an exact match for the Python example and it's a functional match for the Ruby example. Hence, I can't help but think that PHP and Perl were misrepresented by making them jump through unnecessary hoops that do nothing but make the language look more complicated.
  - grncdr 15y ago
    I agree with your general point, but feel I should point out that this is possible in python using properties: class Int(object): def __init__(self, value): self.value = value @property def value(self): print("Accessing value") return self.value @value.setter def value(self, value): print("Setting value") self.value = value

grncdr 15y ago

Speaking of ridiculously verbose, if they're going to pull in Moose to do OO in Perl they could at least use it's ability to provide default arguments instead of abusing BUILDARGS: package Int; use Moose; has 'value' => ( is => 'rw', isa => 'Int', default => 0 ); no Moose; Of course, Moose (while awesome) is hardly the only approach to OO in Perl: package Int; sub new { my $cls = shift; $cls = ref($cls) || $cls; my $val = shift or 0; bless \$val, $cls; } sub getValue { ${$_[0]} } 1; Rather than wrapping the scalar int inside another data structure to be treated as an "object" it's possible to just take a reference and use that as our object. So in this case getValue is really just a verbose way to dereference ($int->getValue vs. $$int). If you don't care about inheritance you could also take out the first two lines of ``new`` and just have: package Int; sub new { bless \($_[0] or 0) } sub getValue { ${$_[0]} } 1; Disclaimer: this kind of code is usually considered terrible Perl style and why people have such a hang up about the language, don't take this as idiomatic Edit: Just noticed that they seem to think instance variables in Perl are private by default. Not sure where they got that idea? I guess Moose attributes are read-only by default, but that's hardly the same thing.