[wp-trac] [WordPress Trac] #18785: Modernize screen functions

[WordPress Trac]

#18785: Modernize screen functions
----------------------------+------------------------------
 Reporter:  nacin           |       Owner:  nacin
     Type:  enhancement     |      Status:  assigned
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  3.3
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |
----------------------------+------------------------------

Comment (by nacin):

 Replying to [comment:38 azaozz]:
 > 1. It goes against the notion of OOP. Base classes like this one should
 be easily extendable and have the basic methods that handle common usage.

 No it doesn't. OOP does not enforce inheritance. It allows for it. This is
 not a base class. It is a class. The class is designed to leverage the
 concepts of modularity and particularly encapsulation, not inheritance.

 > However WP_Screen is just a collection of private and semi-private
 functions that rely on filters and globals. It has no methods to handle
 the most common usage and has no methods that can be extended easily for
 handling more advanced usage.

 Most of these filters and globals exist for compatibility reasons. Over
 time, we will be able to remove them. As stated above, the point of this
 object is encapsulation, not inheritance.

 > On top of that it can be re-initialized and loose all processed data.

 Currently, yes. It's also no different than how set_current_screen()
 worked in 3.2, which is why I reverted the code that prevented re-
 initialization. I agree that losing the processed data is lame, but this
 is an isolated issue we can fix, not a problem with the class as a whole.

 > In that terms we have three options:
 >
 > - Forget about OOP and separate the functions. There's no benefits of
 them being in a class (and it will make the code shorter).

 See above.

 > - Make WP_Screen a pseudo-singleton, mark it as private and discourage
 plugins of ever trying to use it directly.

 Plugins won't be using it much directly at all. It already is a pseudo-
 singleton, as it is used but once on a page (in a normal situation).

 > - Add methods for the most common usage and make it easily extendable.

 There is no reason to make it extendable at this time. It was marked
 `final` with this in mind.

 > 2. It is a (very) bad idea to derive HTML IDs from translatable strings.

 Correct, it is. Again, this is not an indictment of the entire class, but
 rather a single issue that does deserve a fix. I'll work in mbijon's
 patch.

 Are there specific issues with the code beyond HTML IDs?

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/18785#comment:41>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software