[wp-trac] [WordPress Trac] #31985: WP_Network class

WordPress Trac noreply at wordpress.org
Wed May 27 14:49:02 UTC 2015


#31985: WP_Network class
--------------------------------+------------------------
 Reporter:  johnjamesjacoby     |       Owner:
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  4.3
Component:  Networks and Sites  |     Version:  3.0
 Severity:  normal              |  Resolution:
 Keywords:  dev-feedback        |     Focuses:  multisite
--------------------------------+------------------------

Comment (by jacobsantos):

 Replying to [comment:14 johnjamesjacoby]:
 > Replying to [comment:13 jacobsantos]:
 > > Programmers who use static methods quickly realize how much of a
 mistake it is to do so.
 > Not all programmers, and not all methods.

 I find that those who don't, realize sooner or later that they made a huge
 mistake. In truth the amount of patterns where class methods are
 acceptable are minimal. Singletons, Registry, and languages where
 functions don't exist.

 The realization that static methods bar inheritance, make testing more
 difficult, among other problems shine a light into why class methods
 should be avoided at all costs unless absolutely necessary and with good
 reason. I find that whenever I attempt to make a method static, what I'm
 really looking for is a singleton. Then I realize that what I'm really
 looking for is breaking the class out into smaller classes or creating a
 separate function.

 If you are merely attempting to refactor existing code, then that is an
 acceptable reason. Provided that at a later date, they are sorted into
 instance methods.

 > > What reason are you defining class methods instead of instance
 methods?
 > For identifying and encapsulating existing procedural code, so we can
 work backwards from what currently exists.
 Great! Right. I read that in a book once a while back. I'll help.

 > > Are you attempting to create namespaced functions? If so, then what
 benefit do you achieve outside of just creating a function?
 > None yet, other than developer sanity by identifying the logic flow
 (which currently spans several files) and isolating it to one convenient
 location to iterate from further.

 I will suggest interfaces. Interfaces are awesome with process flow.
 > > Are you mixing class methods and instance methods? Do the class
 methods amount match or exceed the instance methods count? Would you be
 better served creating a separate class for the static methods?
 > Yes. CRUD actions will be broken out into a `WP_Network_Query` class.
 >
 > > Do you wish to break extensiblity? If so, then why not just use
 'final'? If you decide to use 'final', then what problem are you truly
 attempting to solve? Would your solution be better if it used functions
 instead?
 > No? Not sure why this is mentioned here in this way. The current core
 code is really only extensible because core developers needed it to be for
 WordPress.org. No flexibility has been added or removed in any patches
 presented here. It's entirely likely there will be 10 or more iterations
 before we agree on a final solution.

 My ultimate goal is to attempt to show how WordPress could be more
 flexible and testable. One way of doing that is by using interfaces and
 creating code that is composable. I should have an example at some point
 in the near future. I am busy with another short project.

 Actually, the presentation might be able to help describe what I mean. I
 should have a video tonight and a better one Friday.

 > The patches presented so far are not prestine candidates for core, but
 rather two people unwinding a messy portion of the codebase that's gone
 untouched for several years, and several years again before that.

 I didn't think the WordPress MU stuff that was that bad. Of course, I
 never truly looked at it. I might have burned it from my memory.

 > I, for one, appreciate your feedback, and also look forward to your
 helping apply that feedback towards future patch iterations working
 towards the final result, if you're willing and able.

 I will be able to submit a patch Friday or Saturday at the earliest. I am
 guessing you might have a few more iterations available at that time. Or
 maybe not. I have also been reviewing WP_Widget that I also need to submit
 a patch for to show an example of what I mean for that. Not really
 relevant, other than I'm attempting to better show what I mean with code
 examples.

 I think once I get to the unit and integration tests, it might make more
 sense. Or maybe not.

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


More information about the wp-trac mailing list