[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