> Quick comments: > > On OOP and not being convinced. What other approaches are you hinting > at? OOP being well understood is a valid argument only because > inheritance and OO does provide reuse. If you have something that > does work in many cases, you are allowed to factor in popularity and > understandability.
For example, the widget plugin that I pointed to. I keep talking about it so I'll just link to it again: http://dev.jquery.com/~john/plugins/widget/widget.js This is a case where many of the problems (or complexities) that exist in advanced jQuery plugins are already taken care of: extensibility, encapsulation, and reusability. I consider this to be a good example of introducing a selective piece of jQuery functionality that'll help developers but without doing a wholesale import of OOP techniques. > Why do you think this would contribute to jQuery bloat anymore than > jQuery.UI does? Because jQuery UI isn't, or doesn't, have the ability to become a dependency for nearly every plugin created. As I mentioned before, most developers look at the tool of Classes as the be-all and end-all of development patterns. Introducing that in a sanctioned manner will instantly make it a dependency of countless plugins, at which point we would be required to include it in core, out of necessity. It seems like it would be a much better option to produce a plugin/widget construction utility that solves all the problems that advanced jQuery developers encounter, in a style that meshes well with the jQuery philosophy, rather than a wholesale import of OOP concepts. --John --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
