Why do people often omit public / private / protected when declaring a class?

Question

I see this format in the latest codes and even here:

class Class { function this() {} } 

instead

 class Class { [public/private/protected] function this() {} } 

• Is it always recommended to specify the scope?
• Isn't the first old approach?
• As in the first approach, certain private and protected functions?

Answer 1

when you declare a function without a public keyword, by default.

Is it not recommended to always indicate the scope?

You need to determine the scope of the function if you intend to use it as confidential or protected.

Isn't the first approach old?

What's old and new if they are still accepted by PHP.

How, in the first approach, are certain private and protected functions?

you cannot use keywords from the first approach.

Answer 2

• Yes it is possible.
• It is difficult to determine how new or old a technique is. It may have been less recommended in the past when classes were relatively new in PHP.
• Class methods can be defined as public, private, or protected. Methods declared without any explicit keyword of visibility are defined as public.

Answer 3

The PSR-2 encoding standard explicitly requires the visibility modifier to be used for both properties and methods .

Using public not required, although due to the fact that PHP 5 and 7 are backward compatible with version 4, which has only public visibility for everything, it is therefore the default value.

However, omitting it, you will ask questions - just like you. People are very good at patterns and mistakes. What would you think of a piece of code that uses protected or private everywhere (because you need it), but accidentally omits public . This is mistake? Was this done on purpose? What secret behavior should be caused by this? Or is it still PHP4 code that hides some unpleasant compatibility issues? As a developer, you do not want to ask these questions, and you do not want to find the answers.

public is optional, but PSR-2 decided to require it. Go with the standard recommendation.

Also note that there was a suggestion to remove and remove the var modifier for properties and completely replace it with public . The proposal also contains code analysis of the top 10,000 Packagist packages, which indicates that 94% of all classes in this code base use public exclusively, the remaining 6% of classes using var come from four large packages, which are likely to continue try to be compatible with PHP4, and "Simpletest" (the unit test framework focused on PHP 4) leads.

There is no such static code analysis for visibility modifiers for methods that I know about, but the trend is clearly noticeable: get rid of old PHP4-isms.

Answer 4

• Yes it is. It is always recommended to indicate the visibility of a function / property.
• Yes it is. The version without visibility modifiers was before PHP4. With the introduction of PHP5 visibility modifiers. Due to backward compatibility for legacy code, a version without visibility modifiers is still accepted and processed as if a public visibility modifier exists.
• PHP4 did not know anything about visibility, so you cannot define private or protected members using this syntax without a visibility modifier.

Answer 5

PHP was born as a (lazy, duck, typed ) scripting language, and people still use it that way. Most PHP programmers have no idea what OOP is, I know this problem very well because I started with PHP, and it cost me a lot of work later. About 90% of the PHP code you see around is random and outdated by object orientation, readability, encapsulation, etc ... At least 50% is pure shit. :(

I can't tell you how OOP programmers are surprised when they discover that “dependency injection” is actually considered an innovative design pattern by PHP developers, and this needs to be explained.

However, PHP4 did not have visibility operators that were private or secure. At that time, you used to declare a method that adds one or more underscores to the method name to indicate that it is not intended to be called from external classes.

• Yes recommended
• Yes, this is the perspective of OOP
• Naming conventions that we hope should be understood by customers

Answer 6

Satisfaction and closeness of PHP4.

Some developers (like me) omit accessibility modifiers because they have little effect on scripting languages. Real OOP languages, such as Python or Javascript, do not have private or protected attributes and do not need it. In PHP, this is slightly different, but it doesn't make sense to always use this syntactic sugar. I will personally do this to reserve it for useful applications.

Many PHP coders are unaware of the original purpose of “encapsulation,” since this does not apply to unrelated code outside of logical visibility. This actually adds a bit more fragility to PHP, since it explodes errors at runtime rather than compilation time (e.g. in C ++).
And I can’t hold back the repetition of this: many coders also use it solely as an idiomatic cult programming language to mimic Java-like syntax (to make up for the perceived / missing PHP OOP structures).