Re: Kinds of methods


"Daniel T." <postmaster@xxxxxxxxxxxxx> wrote in message news:postmaster-D8AFB7.13213222032006@xxxxxxxxxxxxxxxxxxxxxxxxxx
In article <8sfUf.136$B_1.119@edtnps89>,
"Oliver Wong" <owong@xxxxxxxxxxxxxx> wrote:

Then, I'd merge the producer which
creates new objects with the provider which returns objects.

I kept them separate because the two methods have very different
semantics. Multiple calls to a provider return the same object, whereas
a producer creates a new object for each call.

I would not force a "factory" or "provider" to returning ONLY new objects; particularly, if the objects being returned are expensive to create and are immutable, it's often useful to cache already created objects, and reuse the same instances of them when possible.


I'd probably end up with something like:

Setter
Getter
Factory
Mutator

What is the difference between a "Setter" and a "Mutator" in your
scheme? What is the difference between a "Getter" and a "Factory"?

A setter method modifies the apparent (or external) state of the object which owns that method. A mutator changes the apparent state of the object which you pass in, but not of the object owning the mutator. E.g.

"Foo.setX(bar)" would change the state of Foo (perhaps depending on the state of bar), while "Foo.mutateX(bar)" would change the state of bar (perhaps depending on the state of Foo).

A getter method gives the caller access to the apparent state of the object, while a factory "creates" (or returns handles to already existing) objects which are not part of the state of the object.

For example, if you had a random number generator, and you called the "GetNextRandomInteger()" method, conceptually, this is a factory method, in that what it returns is not supposed to be related to the state of the random number generator at all (in practice, most RNGs are actually pseudo-RNGs, and so they DO have state, and their output IS dependent on the state).

I could see changing the name of "producer" to "factory" in my list, but
I figured that the term already has a rather strong connotation of a
member-function that returns something that must be deleted, and I
wanted to include member-functions that return by value.

I felt "producer" also has the connotation of "making something new", which I'd like to avoid. So from my point of view, the two terms are equal in that respect. However, I felt "factory" was more "standard".

But then there are functions which just return a value based on its inputs,
without setting, getting, making, or mutating anything. E.g.

number function double(number n) {
return n * 2;
}

The above is a producer, it creates an object.

Hmm... what about the concept of a pure function, in the mathematical sense? That is, a mapping from a domain to a range? Is that "creating" objects, or is it "getting" states, or something else?


And then there are functions which produce side-effects in the system,
without affecting the objects themselves. E.g.

console.write("Hello World!");

I guess you could argue that this write() method is affecting the state of
the conceptual console (of which the console object is acting as a proxy
for), but then you'd have these "black hole setters", where you're setting
some state which you can never actually retrieve again.

I would indeed argue that, and I see no problem with "black hole
setters".

The problem with "black hole setters" is that the state you're setting is not external or apparent, and so there's a lost of 1-to-1 association between setters and getters.

I suppose if we go with "black hole setters", we could talk about "white hole getters", which get state seemingly out of nowhere (i.e. "producers" or "factories").

- Oliver

.