Augment native objects

A

Asen Bozhilov

I want to create design which augment native objects with some
additions from ES5 and user defined properties. I don't want touch
explicit build in prototype objects. I want to provide this
possibility to user of my code and possibility to create own additions
which augment native objects.

var Lib = {
additions : {
Array : {}
},
importAdditions : function(add_prop, o)
{
augment(o, Lib.additions[add_prop]);
return o;
}
};

var arr_additions = Lib.additions.Array;
if (typeof Array.prototype.forEach != 'function')
{
arr_additions.forEach = function(){
//do forEach
};
}

/* augment instance object */
Lib.importAdditions('Array', []);

/* augment build in `object' referred from `Array.prototype` */
Lib.importAdditions('Array', Array.prototype);

Of course i know all disadvantages of this pattern, and if i port in
real project, I'll be write documentation.
I am wonder, what is opinion on members of c.l.js about this pattern
and similar?

Thanks in advance.
 
D

Dmitry A. Soshnikov

I want to create design which augment native objects with some
additions from ES5 and user defined properties.

Fair enough.
I don't want touch
explicit build in prototype objects. I want to provide this
possibility to user of my code and possibility to create own additions
which augment native objects.

That means you let the user to choose whether he/she wants to augment
built-ins or not, right? And if so, to do this by their own hands
(with full responsibility of the user), yeah?

Calling e.g. this one:
/* augment build in `object' referred from `Array.prototype` */
Lib.importAdditions('Array', Array.prototype);

Yep, this case is fair also. Although, there can be special config
option of your library such as `config.augmentBuiltIns = true;' (or
separately for each (available for augmentation) built-ins).

/* augment instance object */
Lib.importAdditions('Array', []);

Yeah, also can be useful.
Of course i know all disadvantages of this pattern, and if i port in
real project, I'll be write documentation.

You know all yourself. The user of your library should understand all
the consequences and make decision himself (including own
augmentations of built-ins by the user: will he also augment the built-
ins, or as a user of you library, will make an own namespace).

But for some (many) users, if you provide some plugged-in
functionality - it can be good decision. Some of them can still patch
your implementation (for their own risk).
 I am wonder, what is opinion on members of c.l.js about this pattern
and similar?

What exactly meaning do you expect? This topic was discussed several
times.

/ds
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,764
Messages
2,569,567
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top