Array.prototype and DataTable.Api

dma_k

The problem is quite exotic, however may be applicable to some cases, like mine.

Supposing I have another module, that extends the functionality of JavaScript arrays with extra functions, e.g. defines functions like Array.prototype.shuffle(). Now looking at DataTables code I see that some of the functions are populated from Array.prototype space (join(), pop(), push()), some are provided with optional implementation (filter() indexOf(), map()).

Combining two above is not pretty simple as from one side I don't want to many code lines like this:

$.fn.dataTable.Api.prototype.shuffle = Array.prototype.shuffle;

from another side populating whole Array.prototype to DataTable.Api may perhaps break DataTables. Maybe it would make sense to copy all Array.prototype to DataTable.Api but shield / add functions which are needed for correct DataTables functioning?

P.S. Calling toArray() is not best option for me, as number of rows is huge.

allan

If I understand correctly, you basically want to add your extended prototype methods to DataTables' API - is that correct? There isn't really a way of doing that, other than to modify the DataTables code, or to extend the DataTables own prototype as you suggest.

Modifying the prototypes is something I want to have DataTables avoid doing, since it could be included on any page and I don't want to risk breaking things - as such, the code doesn't really make any allowances for modified prototypes.

The reason I haven't just copied all of the array methods to the DataTables API is that I want to document and support each individual one. That way we can be sure that they exist and work the same way regardless of browser and Javascript version implemented.

Having said that, if you did want that behaviour, you could readily do your own prototype extend, as above, but in a loop. Just check if the API already has a prototype for the method to be attached - if it does, ignore it, otherwise attach it.

Is toArray() too slow? Its just a slice(), but if the data set is large, its going to eat a chunk of memory...

Allan

dma_k

The reason I haven't just copied all of the array methods to the DataTables API is that I want to document and support each individual one.

I understand that. Thanks for explanation. Perhaps "complete" array support can be implemented as additional option or a module. In current implementation the potential traps are the following:

• Supposing the module arrays.js that populates Array.propotype is included after dataTables.js. In this case e.g. filter() method may behave differently in "ordinary" arrays and "DataTables" arrays.
• Supposing the module arrays.js that populates Array.propotype is included before dataTables.js. In this case DataTables will use the provided function filter() which may not behave as it expects and differ from description in documentation.

Perhaps there is no golden solution, but I would say, perhaps DataTables should focus on it's main goal and delegate "arrays" emulation to another module (in case these functions are not used internally). There could be also setting "override" ("false" by default), which if enabled, always overrides all prototype functions with provided implementation.

Is toArray() too slow?

It's not slow, but eating memory aggressively and we have big amount of table rows. So I would like to avoid it if possible.

allan

Yup - all good points! This is the problem with changing global prototypes and why (at least imho) is it a bad idea. It can be useful, I fully acknowledge, but if one were to add a filter method that is not compatible with the more recent ECMAScript releases, then its not just DataTables that is going to suffer.

The use of arrays in the API is core to how the API operates - just like it is in jQuery which uses a similar approach (can't remember if it uses the prototype for filter, but it certainly does for other array methods).

Allan