Re: Terms for method types?
- From: VK <schools_ring@xxxxxxxxx>
- Date: Sun, 15 Jun 2008 07:32:06 -0700 (PDT)
Thomas and Rob,
first of all thanks for your responses.
Secondly, you seem misinterpreted my question, which is most probably
caused by the fact that I illustrated each method type by a code
sample: so you commented to these particular samples and their nature.
Other words with a question like "The fruits, say this apple: what can
we say about fruits?" the answers came to "About this apple we can say
that..." :-)
To facilitate the needed level of abstraction I am interested in right
now let's abandon for a second any particular code samples of a
particular language so being using an abstract OOP model.
In such model we have a template of some kind to produce object
instances with identical set of initial properties. An attempt to call
such template "a class" in the sense "a class of things", "a set of
things of the same kind" in application to Javascript usually gets a
furious offense at clj because of possible misinterpretation in terms
of class-based inheritance. It worth mention that such rigorous
terminological approach is not sustained by the current ECMA-262 3rd
ed. documentation where "class" as "kind of this object" is freely
used, see for instance "8.6.2 Internal Properties and Methods".
From the other side an equal offense can be put from the class-basedprogramming point of view on using "a prototype" in the sense "a model
on which something is based or formed". With the same reason C++'er or
Javer may argue that "C++ doesn't have prototypes, it is a class-based
language". Other words the parasite meaning of "a prototype" from one
end is as strong as "a class" from the other one.
At the same time it is plain ridiculous to affirm that there is not a
common underlaying idea behind both paradigms: they are both OOP-
based. If "a prototype" and "a class" are not suggested as terms in
common descriptions as bringing too much of parasite context, we need
a term free of such context yet commonly understood so not requiring a
definition of its own. I see such term either as "a template" or "a
model" being open for alternative proposals. So far and further in the
text I'll be using "a template".
By having a build-in or custom made template, we can create new
instances based on such template. Each new instance will have the same
initial set of members. These members can be either properties or
methods. The properties can be read-only, read/write, write-only. The
methods can be also called, so being subroutines attached to an
object.
btw it is another terminological problem to solve at least in
application to Javascript. The initial OOP distinction was "properties
and methods forming the set of object members". The term "a member"
seems faded away by now. At the same time the higher level Javascript
programming (Mozilla XBL and Microsoft HTC) as well as many other OOP
languages do have a strict distinction between primitive "field"
property and getter/setter based "property" property. That prevents
from saying "fields and methods forming the set of object properties"
due to possible misunderstanding. As the result it is common to see
the term "a property" being used both as an opposition to "a method"
and in the generic sense "a member". The resulting oftenly seen or
implied descriptions of the kind "properties and methods forming a set
of object properties" are sub-optimal to say the least IMO.
Any thoughts or proposals?
To continue from where we stopped:
By having a build-in or custom made template, we can create new
instances based on such template. Each new instance will have the same
initial set of members. Some of these members may be instance methods
we can call.
By their internal representation and by their external behavior there
are three generic types of methods:
1) A method being internally represented by a single entity. The
object instances do share this entity. Each instance may call this
entity and for the period of call an appropriate context will be
created within the method with say "this" pointing to the calling
instance so making possible to operate in the context of call with all
other instance members. On call end the context gets released and the
method is again formally "of no one's" until the next call. Basically
it is the only type of method the original OOP model have planned,
because instance individualization was assumed to be done over fields
and properties change, with shared methods to manipulate these fields
and properties per instance yet keep the memory usage to its minimum.
This type of method I am calling "shared stateless" being open for any
other proposals on the conditions of i) not using "static" word
because of semantical slash between different programming languages
and ii) not implying any particular programming language and iii)
being meaningful from its own.
2) Nevertheless Her Majesty Encapsulation states that whatever can be
potentially hidden - it must hidden. This caused the appearance of
methods appertaining to their respective owners. In this case in
application to methods the template is working as a factory, so for
each new object instance a new clone of the method is being made. From
one side it is a "memory killer" because for N instances N identical
methods are created instead of just one shared as in case 1). From the
other side it allows to shift the further individualization of
instances from its fields and properties into encapsulated context of
the method clone.
This type of method, being cloned for each instance and able to
preserve its context between calls, I call "own state preserving" and
I'd really like to have a nicer one on the conditions of i) not
implying any particular programming language and ii) being meaningful
from its own. This is why Rob's suggestion of "closure", however
evident it would be, alas is not suitable.
3) The third and the last type of method is more or less Javascript-
specific. It appeared as a quick'n'dirty way to break parasite
closures introduced with nested functions paradigm. I will be using
this type for criticism only yet it still has to be called somehow :-)
Basically it is the same "own state preserving" type as 2) but with
the context preserving removed. Other words for N object instances N
method being cloned with the instance-specific context being re-
initialized for each call.
I call it "own stateless" and I am open for other proposals.
.
- References:
- Terms for method types?
- From: VK
- Re: Terms for method types?
- From: RobG
- Terms for method types?
- Prev by Date: Re: Safari and className oddity?
- Next by Date: Re: How do I get HTML sent to server?
- Previous by thread: Re: Terms for method types?
- Next by thread: Re: Terms for method types?
- Index(es):
Relevant Pages
|
Loading
