Re: Abstract public member variales?

Dmitry A. Kazakov wrote in
news:3jty6lxzzk5o$.1swpqox9fs2vv$.dlg@xxxxxxxxxx:

On Mon, 11 Sep 2006 17:45:37 GMT, Brendan Guild wrote:

Just to be clear, when I say 'property type' I'm using domain
terminology. I do not expect property types to actually be
represented by types.

That's a strange decision. If the groups of similar properties in
the domain aren't mapped onto groups of objects of same type,
then?

It depends on what you mean by similar. All properties represented by
numbers will be of the same type in the language, and so will all
properties represented by strings. I do not think there is any
benefit to creating more detailed types than that. But of course I am
using the technical meaning of 'type'. In the domain, the set of
property types will be very detailed.

The entities could be like pieces on a chess board. They are used
as tools by the client and moved around according to the rules. I
don't think that they need to know anything. In fact, I have
plans to divide entities into two subclasses: Animate and
Inanimate, which will represent whether the entity has motivation
to move itself. The Inanimate entities will have absolutely know
use for their own properties, but the properties will affect how
the animate entities behave towards the inanimate ones.

This "affect" is what? Under "know" I mean the following mechanics
of "affect":

1. When Entity knows a Property => the current value of the
Property is available to Entity => the behavior of Entity can be
parametrized by this value.

That is true for some entities with some properties, especially
animate entities. But each property type has different semantics and
is used in a different way and known about by different objects.

2. When Entity does not know it, then its behavior cannot depend
on Property. As a consequence, you need some outsider, which would
choose an appropriate behavior according to the current state of
Property. This outsider could be either the Property (= Property
knows Entity), which would be a delegation model, or else there
must be someone third who puts things together.

A property does not know about entities, but there is an outsider,
called 'the client' who chooses an appropriate behaviour for the
entities. The client works with some properties, entities work with
other properties, and different entities work with still other
properties.

When you call Get it returns a new object of the type Property,
which is a copy of some other object, contained by Entity. If
Property are big, you might wish to use a referential semantics,
based on some sort of GC, etc. BUT semantically that would
change nothing, because the returned Property (a handle, smart
pointer to some Property_Implementation, invisible to the
clients) still had value semantics.

I have been thinking of making individual property objects
immutable, but it has also been suggested that I replace the set
method of Entity with something that the client calls in this
way:

Instead of: entity->set(propertyType,property)
The client would call: entity->get(propertyType)->set(value)

Altering the value semantics of the property instead of replacing
the property.

I don't see any difference in the variants above. In both cases
you set a value. The second variant returns not a property, it
does an iterator, or a reference to the property to set.

That is true, but the difference I was trying to point out is that
the first has value semantics while the second has reference
semantics.

You know, MD is a fundamental thing, either you have it or not.
When you do, then even if you weren't aware of that, it will
proliferate your design in the form of quite ugly patterns. BTW,
the check is very simple, draw a chart: Entry'Class \
Property'Class. It is a simple matrix rows are types of
entities, columns are types of properties.
[snip]
I am sure that the matrix will not be square, since I expect to
have just two types of entities and many property types, perhaps
hundreds of property types.
[snip]
It is always square, just some cells might be never reachable in
any [correct] program.

This needs more explanation. I can take your word for it that the
matrix is always square, but I can no longer picture the matrix. The
matrix I see has far more columns than rows because I have far more
property types than entity types.

Do you mean that I cannot have more property types than entity types,
or perhaps that I simply do not have more property types than entity
types, even though I think so? My guess is that you did not describe
the matrix that you intended.
.

Relevant Pages

  • Re: Abstract public member variales?
    ... domain was about cars, you could make red cars and black cars ... tools by the client and moved around according to the rules. ... Property are big, you might wish to use a referential semantics, ... Therefore, I started calling 'age' a property type, while ...
    (comp.object)
  • Re: What doesnt lend itself to OO?
    ... > rather than client code. ... no way to do that without also touching the object with clock semantics ... will not encapsulate both clock semantics and network semantics. ... The server can do whatever it wants ...
    (comp.object)
  • Re: Abstract public member variales?
    ... [The issue of string representation is a different thing. ... When semantics sufficiently depends on both ... This outsider could be either the Property (= Property ... or a reference to the property to set. ...
    (comp.object)
  • Re: Is this bad design?
    ... What a Client needs is access to the R2 collection class so it can "walk" the site members. ... So if getGroups returns a handle to that collection class, that is standard relationship navigation that is orthogonal to the class semantics of. ... That's because the getGroups is then a collection responsibility so one is duplicating the R2 collection management semantics in the definition in addition to its other responsibilities in the problem solution. ... It allows one to separate the concerns of WHO participates in collaborations from the concerns of WHEN the collaboration should occur. ...
    (comp.object)
  • Re: Whatever happened to reuse?
    ... > To be reusable the specific implementation of functional semantics must ... > be hidden from the prospective client. ... The interface allows the client to access the semantics of ... Even the interfaces for a dumb data ...
    (comp.object)