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

[WordPress Trac]

#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 welcher):

 Replying to [comment:18 jdgrimes]:
 > Replying to [comment:17 jacobsantos]:
 >
 To me it just looks like added layers of complexity without actually
 reducing the bootstrap code plugin devs have to write.

 I agree, the interface approach ( at least in the patch provided ) is very
 complicated and I don't immediately see the benefit of requiring a new
 class to implement 4 interfaces rather that extend a single class. As I
 mentioned in a earlier comment, WordPress maintains a low barrier-to-entry
 for developers and for some, doing any OOP may be daunting. I am guessing
 this is why WP_Widget was written to be inherited. There seems to be a lot
 of room for error with having to implement multiple interfaces. If one is
 left out, what happens? The point of an interface is to define what
 methods a class must define, and if that is what where trying to
 accomplish, it may be a better approach to make WP_Widget an abstract
 class with abstract methods and maintain the inheritance model.


 >
 > I think maybe what you envision and what @welcher was proposing are two
 different things. I think you're leaning towards a complete rewrite of the
 whole widgets API, while (I think) what @welcher was proposing was just a
 little bit more abstraction/bootstrap in the `WP_Widget` class.I think we
 need to be more specific about the scope of this ticket. I'm not saying
 your scope is necessarily too broad, but I'm not sure that's what the
 original intent was, and maybe these are sort of two different things that
 should be separate tickets. ??

 That is what I was proposing - more abstraction in `WP_Widget`. I think
 that perhaps a second ticket is in order as @jacobsantos approach would
 require a major rewrite to the API and is beyond the scope of making
 enhancements to what is currently in place.

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