Re: How to create descendants of Array class?
- From: "Richard Cornford" <Richard@xxxxxxxxxxxxxxxxxxx>
- Date: Mon, 24 Mar 2008 17:41:27 -0000
"Thomas 'PointedEars' Lahn" wrote:
Richard Cornford wrote:
[...]
Another role for 'factory'-like functions is adding interfaces
to other objects. This can be analogous to 'subclassing' in
some uses. So we might have the previous augmented array
object and 'subclass' it by passing (some of) its instances
through another function:-
function addSomeInterface(obj){
obj.anInterfaceMethod = forAnInterfaceMethod;
}
function forAnInterfaceMethod(){
return this.y;
}
var instance = addSomeInterface(new getAnObject (3));
However, this "factory" approach (a factory is usually considered
to be something different than this)
You are at liberty to propose a better label for a function/method that
is intended to create instances of a 'class'.
has the obvious drawback as compared to object aggregation
that the augmented object has enumerable properties that
show up in a for-in loop and similar operations, thereby also
excluding certain identifiers from being used as a property.
Which is not a drawback in comparison to adding methods to the
prototype, as those method become enumerable and so have the same
impact, or in comparison to any object acting in the role of an instance
of a 'class' as such objects will tend to have a set of specific
properties added to their instances or prototypes which are also
enumerable. The result is that it is usually unhelpful/impractical to
apply a for-in loop to an object acting in the role or instance of a
'class', and so the consequences of any particular example having
additional enumerable properties are insignificant.
The augmented array facilities direct indexed looping and maintains its
'magic' - length - property. If that is what is wanted from the object
then it can be achieved, and achieved reasonably easily/efficiently.
Whereas the aggregated (Array) object (although just
aggregated through a reference to it by the aggregating
object's property) would allow clean for-in iteration of the
aggregated (Array) object,
Which may be valuable if the array was going to be used as a sparse
array (for efficiency). The vast majority of arrays are not sparse.
On the other hand, the situation of the array as an internal detail of
another abject has the drawback that all access to, and interactions
with, the array would suggest a wrapping layer of method calls. Slowing
the whole process down and introducing at least some additional function
objects into the system.
and would not impose further restrictions on
property names.
I don't see the relevance of that.
The iteration drawback could only be mitigated -- hard to
maintain 'if' statements in the iteration loop aside --
by providing an iterator method that filters out the
properties that are not to be included in the
iteration,
The iteration drawback would not need to be mitigated if the object were
not intended to be the subject of for-in loops.
However, one drawback of the "factory" approach cannot be
worked around: in contrast to object aggregation, it is not
reasonably applicable to host objects because of their
allowed arbitrary [[Put]] implementations.
True.
Richard.
.
- References:
- How to create descendants of Array class?
- From: Tom de Neef
- Re: How to create descendants of Array class?
- From: Richard Cornford
- Re: How to create descendants of Array class?
- From: Thomas 'PointedEars' Lahn
- How to create descendants of Array class?
- Prev by Date: Re: Returning from function (FALSE VALUE) & FOCUS()
- Next by Date: Re: Accessing the global object
- Previous by thread: Re: How to create descendants of Array class?
- Next by thread: Too many scripts
- Index(es):
Relevant Pages
|