Re: Kinds of methods

In article <sFhUf.203$B_1.47@edtnps89>,
"Oliver Wong" <owong@xxxxxxxxxxxxxx> wrote:

"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.

Sure, but logically, it's a new object even if it isn't really a new
object. Often in cases such as you describe, the destructor then
placement new is called on the object to ensure that it is "cleared out
for use." For example see std::vector.


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).

So what is the logical difference between:

class Foo {
public:
void mutateX( Bar& bar ) const;
Bar getBar() const;
Bar factoryBar() const;
};

Bar bar;
foo.mutateX( bar );

and

Bar bar = foo.getBar();

In both cases, some object external to foo is getting mutated, and the
'bar' object's state will be a direct result of foo's state.


What's the difference between:

Bar bar = foo.getBar();

and

Bar bar = foo.factoryBar();

In both cases, the member-function is returning a new object initialized
by the foo object and assigned to bar...

I call all three member-functions producers. They all set up an object's
state based on the state of the object being called.


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.

OK, so a method is a factory if the state of the object it is called on
is irrelevant? I wouldn't call that a factory, I would call that a
mistake. Why is the method a member function if the object it is called
on doesn't figure into what the function does?


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).

Again, seems to me that GetNextRandomInteger shouldn't be a
member-function if the output has nothing to do with the state of the
object it is called on... Maybe I'm missing something?


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?

We aren't talking about pure math, we're talking about OOP. In every OOP
language that I know, a function either creates an object or modifies
one.


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 don't think there needs to be a 1 to 1 association between setters and
getters. In fact, I prefer not to make such an association...

class Foo {
public:
void mouseClickAt( int x, int y );
void keyHit( char k );
};

I see nothing wrong with the interface above despite it's lack of
accessors that are directly related to either of the member-functions. I
could see adding some sort of "getState" member-function for testing
purposes but there still isn't a one-to-one association.

I might be missing something, and I still have to digest HS's post...


--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
.

Relevant Pages

  • Re: Insert with response
    ... FooBar, there's no way and no need to put them in synch. ... column in the foo table to 250 calumns in the bar table. ... set statistics time off ...
    (microsoft.public.sqlserver.programming)
  • Re: Magic function
    ... processing objects created in root at depth 3 ... root obj2 at depth 3 ... processing objects created in foo at depth 2 ... processing objects created in bar at depth 0 ...
    (comp.lang.python)
  • Re: from __future__ import absolute_import ?
    ... foo not in bar ... Unfortunately this is a side effect of using the os's directory structure to represent a python "package" structure. ...
    (comp.lang.python)
  • Re: from __future__ import absolute_import ?
    ... foo not in bar ... A path below the package level is generally a good means to shoot ... to represent a python "package" structure. ...
    (comp.lang.python)
  • Re: how to deserialize variable element/node
    ... string bar; ... In the first deserialization case, bar = "sometimes a simple string is ... Your two XML fragments would have to be represented in an XML schema by ...
    (microsoft.public.dotnet.xml)