ui-dialog, getTitleId method is not in the prototype literal, why?

I want to increase my knowledge concering jquery-ui, so I look at their source code.

I work with jquery-ui 1.19m5.

When I look at the 1.19m5 source code of ui-dialog I see after the call to the widget factory:

$.extend($.ui.dialog, {
 ...
   getTitleId: function($el) {
 ...

I do not understand this. Why don't they put the getTitleID method directly into the prototype literal (the 3rd parameter with the 开发者_如何学Cwidget factory call)?

---

jQuery UI is designed to trigger methods from the appropriate widget API. So to call a method, you would do $('.selector').widgetName('methodName',arguments);

This allows the plugin developer to easily add private/public functions, as well as avoid namespace collision. It is possible to have an object that is resizeable, draggable, and dropable all at one...these three plugins share some method names, such as the enable/disable function.

In this example, if they added it to the prototype under 'enable', this would only allow you to enable/disable the functionality of the last widget you added, making it impossible to have control over all of the widget types. With their API, you can specifically select a widget to modify. Ex. $('.selector').draggable('disable'); which would disable the drag feature, and keep the resizable and droppable widgets fully functional. Keep in mind, many widgets have the same or similar methods, events, and/or option names.

Long and short, it is for namespacing purposes. This also makes it easier on the developer because he only has to worry about the top level widget name when writing his/her own widgets, without worry of what other methods, options, data, etc that has been added to the prototype directly.

They could add it to the prototype under a second layer, possibly, but this doesn't really save you (the user) any time, and probably would not look as clear in code. or they could add a prefix to every single function to specify namespace, but that would clutter your code, and create more checks and potential points of failure for developers creating their own widgets.