[wp-trac] [WordPress Trac] #32470: Abstracting the Widget Classes

Tue Jun 2 15:45:07 UTC 2015

#32470: Abstracting the Widget Classes
------------------------------------+------------------------------
 Reporter:  welcher                 |       Owner:
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Widgets                 |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |     Focuses:
------------------------------------+------------------------------

Comment (by jacobsantos):

 Replying to [comment:25 jdgrimes]:
 > Thanks for the explanation @jacobsantos. I'm starting to see better
 where you are going with this. I can grasp how this will improve the
 testability of the API. And I can also see now that you're not actually
 trying to rewrite the entire API, just to refactor `WP_Widget`.

 Well, my next patch will go into refactoring more of the widgets.php file.
 I think I will create a new ticket for that as it is outside the scope of
 `WP_Widget`. I think there are other areas in WP_Widget that could be
 further refactored. I'm unsure how to proceed with this ticket. Given its
 scope, I was thinking about using the interfaces and testing for it, sort
 of how I shown in my previous example.

 > Ultimately it is the same thing as @welcher proposed in terms of scope,
 but you are reducing the complexity of the `WP_Widget` class itself,
 rather than increasing it. This actually gives us more freedom to reduce
 duplication across the widgets because we won't be tied to having just one
 all-encompassing abstraction in `WP_Widget`, we can have several different
 flavors of widget that implement these interfaces.

 That is part of my goal. There are two others. The second is to reduce
 code within WP_Widget and other parts of widgets.php by further
 abstracting and refactoring the code. The final is to go in and allow for
 certain parts of the existing code base to be replaced. I think I put
 another hour or two into it last night and I'm barely there. I thought
 this would take a day (8 hours) and it still might, but it will be over
 the next couple of days.

 The difficulty is finding a pattern that exists in two or more places and
 creating an interface that matches that pattern. I fear that barring a
 simple low modification patch, it won't be accepted into core. What I'm
 doing is on the level of WP Meta Field changes, which might require far
 more red tape. Granted, I'm going to tackle a few other tickets and apply
 the same techniques to those as well. Perhaps more patterns will emerge
 that will further reduce the amount of code required.

 >
 > >It is my prediction that if WordPress includes better OOP principles in
 the code, that programmers will become better object-oriented programmers.
 >
 > As someone who has learned PHP practices mostly from WordPress, I can
 say that the way I do OOP  is largely based on what WordPress does. If
 WordPress improves, so will I, and many others will too.

 I think unfortunately, that WordPress is the level most programmers stop,
 even outside of WordPress. It takes something like Laravel to go further
 and see the full power of using interfaces. I think Laravel framework is a
 good example, because it strives to be as simple as possible, while still
 giving as much power as possible. I hope this is possible in WordPress, so
 not only would novices have an easier time, the flow of their application
 would allow them to further their knowledge and experience as they
 continue developing with WordPress.

 Unfortunately, some of that power has to wait until PHP5.3. It is
 incredible how using a few generalized interfaces can change the
 application and the patterns it allows.

 > However, there is a difference between growing my knowledge of OOP
 alongside WordPress and a newbie trying to break into WordPress
 development after the fact. I think if it *seems* too complex, it may
 discourage some people from getting in (not necessarily a bad thing, mind
 you). It took both me and @welcher some time to wrap our minds around it,
 but I think in some ways the end product will actually be simpler than
 what is was before, once a dev cracks the entry barrier. And, because
 backward compatibility will be maintained, newbies can continue to use the
 old approach until they better understand the new underlying API.

 The question I have is the reasons behind that and how to allow for it to
 continue while still creating better code. My prediction is that
 contributors and committers won't really consider any previous design
 decisions and will develop their patch at their level regardless. I see
 that with the current stream of patches and contributions. Well, some of
 it might simply be preparing refactoring and may eventually abstract
 further, so I might be too critical at this point.

 I have experienced that as well. I think the problem is the burden of
 design. With WordPress there is no burden of design, because WordPress
 does not suffer from having a design and designer. It is a mash of code
 that works together. It is the hacker's dream, because everything has been
 hacked in. Nothing was considered from the perspective of the original
 author.

 As much as I would like to hope that composition would enter the mindset
 of plugin and theme developers, along with contributors. I don't believe
 it will for all. Part of the noise I'm creating is the futile attempt at
 saying, "Hey hey. Let's design something better." I hope that it might be
 better this round, but past experience has taught me that I'm better off
 working with my github fork.

 I think that part of it is education. Something I regret and will have to
 see whether it makes a difference is that I never documented the reasons
 for why I decided to do what I did when I did them. Something I'm
 attempting to do with the videos and something that needs to be added to
 the handbook. Provided any of my patches are actually committed to core.

 Being able to compose functions is, I think, the next step with clean
 code. Being able to compose objects along with functions is something I'm
 still experimenting with.

 > Note: I see that you are using `static` in
 `WP_Widget_Display_Adapter::factory()`, however, WordPress still supports
 PHP 5.2 (not my fault :-).
 >

 It was example code. I didn't want to do `new WP_Widget_Display_Adapter`,
 because I don't normally develop as far back as support PHP 5.2. Not being
 able to use closures would be a nightmare.

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