[wp-trac] [WordPress Trac] #30891: Unchecked property overloading is detrimental to OOP.

[WordPress Trac]

#30891: Unchecked property overloading is detrimental to OOP.
--------------------------+------------------
 Reporter:  aercolino     |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  4.2
Component:  General       |     Version:  4.0
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------

Comment (by aercolino):

 The fix consisting in removing unchecked overloading altogether and making
 legacy stuff explicitly public is clean, more WYSIWYG and saves clutter.
 However, here are some points to consider.

 (1) '''Everything should be made public.''' Currently, even if modifiers
 say differently, everything is effectively public and has been for all the
 months after introducing unchecked overloading. The safest thing to do
 with that fix would be to ''indiscriminately'' declare public everything
 in a class with unchecked overloading (which is what unchecked overloading
 disguisedly did). This would be a reasonable fix because it would stop the
 bleeding, meaning that no fresh properties or methods would suffer the
 same problem again.

 (2) '''Existing modifiers would be lost.''' Both before and after
 introducing unchecked overloading, core developers have been adding proper
 modifiers, not only expecting them to be honored but also documenting
 their intentions. It's valuable information that deserves some ponderation
 before applying such destructive fix.

 (3) '''Fine tuning checked overloading.''' Whitelisting is definitely
 tedious, but we can fine tune it at will. For example, we could decide to
 apply point 1 to stay safe. It should be easy to extract all properties
 and methods of an ill class and whitelist all of them. Then, as @nacin
 suggested, we could signal incorrect usage on access to whitelisted non-
 public stuff. This is like taking the point 1 and the opposite of point 2,
 which is good.

 (4) '''Non-whitelisted or undefined stuff.''' My idea is to maintain the
 standard outcome when accessing undefined stuff in PHP, but we can signal
 incorrect usage on access to non-public non-whitelisted properties. In
 fact we can easily imagine this to be the destiny of hopefully all legacy
 properties some time in the future. So it could be something along
 [https://gist.github.com/aercolino/b5d34a75bfb2a21d121a these lines].

 (5) '''Migrating legacy to fresh.''' As I briefly hinted at above, for
 improving information hiding along time, i.e. for continuing migrating old
 code to PHP5, whitelisted overloading allows for a smooth path. Along
 time, public legacy properties will first continue being used normally.
 Then they will get more reasonable non-public modifiers and their misuse
 will be signaled by `_wrong_access` notices. Then they will be finally un-
 whitelisted and their misuse will be signaled by `_too_wrong_access` fatal
 errors.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/30891#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform