Re: Abstract public member variales?

On Tue, 12 Sep 2006 18:22:05 GMT, Brendan Guild wrote:

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.

Why? [ The issue of string representation is a different thing. You can
have both different types and string representations for persistence,
networking, debugging etc. ]

I do not think there is any
benefit to creating more detailed types than that.

Benefits are huge:

1. OO programming. You can't define different method on the same type
2. Static type checks

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.

= it is not single dispatch. When semantics sufficiently depends on both
the type of Entity and the type Property that is equivalent to MD.

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.

And how the outsider decides when it makes what? If the decision is based
on the types of Outsider, Entity and Property, that is triple dispatch. If
the decision is based additionally on the values of, that is a total ad-hoc
mess. Surely, you could map everything to one type void*, but that won't
help, it would make it only worse. The problem is not in types, but in lack
of OOA/D, because the responsibilities aren't clear.

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.

Right. But reference semantics is an implementation detail, which does not
influence the problem. [ In some languages reference is always polymorphic
and value is always specific, but these are local language problems. ]

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.

Oops, sorry, it is rectangular of course.

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.

No, forget it, it was just a typo error. I meant rectangular. It is square
for multi-methods for dyadic operations (like +, * etc).

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: Abstract public member variales?
    ... as tools by the client and moved around according to the rules. ... This outsider could be either the Property (= Property ... Property are big, you might wish to use a referential semantics, ... or a reference to the property to set. ...
    (comp.object)
  • Re: Dict sharing vs. duplication
    ... accelerate some interactions while there is only a single reference. ... someone comes up with a better internal representation. ... A ref, the way I see it, ...
    (comp.lang.tcl)
  • Re: Cohens paper on byte order
    ... This was assumed in suggesting that the early evaluation of a bit stream ... that a fractional numeric representation did not have this limitation. ... >> string on a particular machine but this is irrelevant if the bit string ... semantics match those of the objects that they are manipulating. ...
    (sci.crypt)
  • Re: my KDF vs dictionary attacks
    ... Important thing, semantics. ... representation fails to use "both the 0 and 1 of each bit" to represent all the values in ... 1.79769313486232e+308, again for the same reason, the full 8 bytes are not used in displaying a positive or negative number. ...
    (sci.crypt)
  • Re: How come Ada isnt more popular?
    ... casual to the program semantics. ... They share representation in the underlying system / VM / whatever you ... Now a function of the first tree is evaluated, ... with "controlled referential objects" I don't know, ...
    (comp.lang.ada)