On 8/14/2016 11:14 AM, Stanislav Malyshev wrote: > Hi! > >> Today I see 2 sides in PHP Internals. One that truly believes that PHP >> should adopt more concepts of object orientation, such as Annotations, >> Generics, Overloading, Class visibility, Collections, Exceptions, etc > > Object orientation is a very broad term. You can be very well object > oriented language and not be Java. In fact, almost all OO languages are > not Java ;) And a lot of OO languages (most of ones I know) don't have > Javaesque features like private classes, many also do fine without > generics. >
This is actually not accurate:
- PHP 7 has private classes through anonymous/inner classes.
- C++ has private (and protected) classes through nesting and friend
classes.
- C# and VB.NET have private classes and many more modifiers.
- Everything is private by default in Rust.
- Golang (another beginners language) has private and protected (internal).
- Swift has private and more classes.
- Ceylon has the shared annotation.
- Ruby has private classes through some tricks.
- ...
I stop here but you will find more.
On 8/14/2016 11:14 AM, Stanislav Malyshev wrote:
> Please do not forget that PHP was designed as beginner's language with
> low barrier of entry. Making EJB out of it goes contrary to that, and
> introducing features that would serve 0.01% of very complex cases while
> complicating the language model for 100% of the users does not seem to
> be worth it to me.
> Especially if in those 0.01% cases I don't see a lot of real
> improvement, but rather a "good feeling" that you can write "really
> strict" code even though there's nothing better in that code than if it
> were written without all the complexities.
>
I know that the numbers are figurative but I think that 80 to 20 might
be more accurate.
On 8/14/2016 11:14 AM, Stanislav Malyshev wrote:
> I would like to see what is impossible to implement in PHP without
> private classes. I mean useful functionality, not circular reference "I
> need private classes because I need classes to be private" of course.
> What application can not be implemented without it? I have very hard
> time imagining such application.
>
Impossible is such a strong word but lets consider for a second the
following example:
> Create an entity and builder. The entity has to be immutable and
> the builder is the only object that is allowed to create that
> entity.
<?php
abstract class Data {
protected $id;
protected $name;
protected function __construct() {}
protected function __clone() {}
}
final class Entity extends Data {
public function getId() {
return $this->id;
}
public function getName() {
return $this->name;
}
}
final class Builder extends Data {
private $entity;
public function build() {
return clone $this->entity;
}
public function setId($id) {
$this->entity->id = $id;
}
public function setName($name) {
$this->entity->name = $name;
}
}
?>
The biggest problem is that we are leaking the abstract base class that
is required to allow the entity and builder access and thus sharing of
properties and methods. This is very bad because that class has no value
for users but its part of our public API. Hence, any change to it
requires special care AND it gives anyone extending that class access to
the properties as well.
Now consider the whole thing with friend classes or private classes and
its super easy to solve.
Another example that is not solvable with friend classes would be the
strategy pattern of hidden strategies as we find it for example in
Symfony's process component.
https://github.com/symfony/process/tree/master/Pipes
The pipes are purely internal to work around differences between PHP on
Unix and Windows. They are not meant for consumption through users, they
actually never face the user in any circumstance. Their only purpose is
it to abstract these differences between operating systems away from the
user to make it easier for them.
On 8/14/2016 11:14 AM, Stanislav Malyshev wrote:
>> working on a bug fix. If this class was never intended to be used
>> outside of the scope of this project, how can restrict its usage by
>> outside packages? Feel free to provide me answers or alternatives, and
>> I'll happily agree with you that private classes is a bad idea.
>
> You can document it and talk to your users. PHP is an open-source
> software, with open code and open development model. If the code is out
> there, people can use it. If they use it contrary to maintainer's
> recommendations, they take a risk. But that's it.
>
At trivago we have hundreds of applications, packages, libraries and
developers who work in a very fast moving environment. Reading
documentation is not something most people spend time with. This is sad
but nothing anyone can solve. Hence, they use stuff that they are not
supposed to use. Having more control over access would greatly help to
improve control over how other developers use a library.
On 8/14/2016 11:14 AM, Stanislav Malyshev wrote:
> Obviously, if the users used that class, it provided some functionality
> they needed. If you removed that functionality, now the users don't have
> it. It's not a problem that can be solved with access modifiers. In
> fact, if there were access modifiers preventing users from using
> necessary functionality, they'd probably fork the code and removed them.
>
Yes, and that is exactly what they should do. It would be best if they
contribute that code back and let the maintainers know about their use
case. Either its completely wrong what they do and one can help them to
do it the right way or the library really needs changing.
On 8/14/2016 11:14 AM, Stanislav Malyshev wrote:
> Also, working around namespace-private classes is very easy - just put
> your own code in the same namespace. Works for Java too IIRC.
>
It's also easy to work around property and method access modifiers.
However, that is no argument to remove them now.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
