Re: identity...... Was: The wisdom of the object mentors


Dmitry A. Kazakov wrote:
On 8 Jun 2006 03:55:19 -0700, Mark Nicholls wrote:

Dmitry A. Kazakov wrote:

Hmm, how are you going to check such types? I mean the propositions that
are true but cannot be proved, due to incompleteness?

then you have objects that potentially are conformant with a type
definition but not provably....some things are true and not
provable.....makes compiler design a tad hard.

Impossible, you mean... (:-))

errrmmmm, a perfect compiler.

I think you could have warnings along the line of
"could not prove variable on line 123 is of type Apple"....it's a bit
of a cop out, you could write a valid compiler that says.
"could not prove program works".

(I'll ignore actually creating the executable.....as beyond me to even
comment on).


what I am refering to is...

class 2DVector
{
// this is it's state
private int[] state = new int[2] { 0,0 };
....

....

// this is it's implementation/mapping from a hidden domain of {int x int}
void SetYCoord(int newY)
{
// !!!!! how does the implementation access it's state....noone else.s....
// the state that is uniquely *identified* with the object?
// answer using "this".
this->state[2] = newY;
}
}

Fine. Now, I see the word "int" there. What is the states of? What is the
state of state[2]? What is the state of the result of "new int[2]"? What is
the state of 2?

I don't care what it's internal state is, only it's behaviour.

But you seems to care about the state of 2DVector. Why?


I was attempting to demonstrate my interpretation of identity...as in
construction mechanism.....for this I need to show a construction!

Ultimately I will get down to some state representation in terms of
sets.....(if I choose ZFC).....or bits (if I choose digital
computers).....tape if I choose Turing machines.....integers are far
enough really....I 'believe' in them enough not to worry too much.
[...]
I can construct the integers using ZFC in the normal manner....it is
consistent with the model.

lets not use '->' lets use '.', and then I don't need pointers for the
moment.

I am not claiming to know all the answers and be able to write an OOP
tomorrow that supports all this....I am simply claiming to have some
interpretations of concepts that are useful and incisive (to me), but
seem differently labelled to yours.

OK, but integer is a real world object. It is not int. What is int?

OK...

seperating implementation from interface;

IInt is a type.....
int is a class....so the above construction should read

class 2DVector
{
// this is it's state
private IInt[] state = new int[2] { 0,0 };
....

....
// this is it's implementation/mapping from a hidden domain of {int x
int}
void SetYCoord(IInt newY)
{
// !!!!! how does the implementation access it's state....noone
else.s....
// the state that is uniquely *identified* with the object?
// answer using "identity".
identity.SetState(identity.GetState()[2] = newY);
}
}

I've changed the name of 'this' to 'identity' and removed the '->'.
identity has 2 methods GetState and SetState.

Is int
a class?

yes an implementation

What about classes of ints?

? don't understand the quesion ?

different implementations of int?
The question to me doesn't make sense.
different implementations of IInt?
This does make sense to me.

Can I derive from?

as said derivation is a construction mechanism I am not too happy with.
Yes you probably can.
In general the derived class will *not* be a subtype.
Though I think there are very strict scenerios where it can!

Can I have
supertype of?

the same answer the other way around

Same with pointers.

I want to exclude pointers....at least for the
moment....basically...."no comment".

You have to answer these question because
otherwise your system would be incomplete.


I am not constructing a system.
I am applying concepts to existing systems, and then making naive
statements with naive examples, they are not supposed to be taken too
literally, and am interested in your notions because they may make mine
less naive.

void Bar::Foo
{
this->Baz ();
// Get a pointer to an object of class Bar (=this)
// Dereference the pointer (gives an object of class Bar)
// Call method Baz on the object of class Bar (dispatch)

Baz (); // A syntax sugar for the above
}

I am not really interested in private interfaces except in the context
of accessing state....then we can simply define 2
methods....GetState(), SetState()......all else is just implementation
detail.

OK, but that detail is written in a language, so there must be an
interpretation of that's going on.

I'm not very good with the interpretation of variables, I've never
really got my head around it.

What about - variable is a named object - as the first iteration.

in the language....OK


I think I like to think of them as prefixed labels.

e.g.

the variable I is really In.....i.e. when we go I = I + 1....

we're really going I<n+1> = I<n> + 1

SetState(value)....would then be going....

State<n+1> = value.

GetState(value) would return the 'current' State<n>....

what does my head in is GetState needs to know the current 'latest'
value of 'n'.

n is the computation state. For each variable there is a mapping from S
(the set of computation states) to V (the set of values of the variable's
type T). The notion of computation state, basically removes any need in
mystical object states and other mess like that. Everything becomes
functional (no pun (:-))

Thats makes sense....

the thing about 'objects' is that their state is hidden, it's not in
the program......I can map it into the program, by messing with the
signatures (like Rumbaugh C...with knobs on).....but then the sense of
object becomes a 'path' of states...which sort of actually makes
sense.....but OO people would probably get uptight....it seems slightly
etheral, objects do not really exist, except as paths in a program!


The language confusion is doing my head in.

loosely.

type = { set of propositions }

I'd say that the set of all propositions is language defined behavior or
semantics.

?

a type is just a set of propositions in the language....not the set of
all propositions.

It is a proposition about the type...

it is a set of formulae with a free variable (lets just do 1 per
formulae for the moment).
The set is the "type".
We can reason about this in isolation from concrete sets of objects
(which I thought you wanted from previous conversations).
When we resolve this against the universe and get sets (possibly empty,
possibly empty forall universes), that 'obey' the type definition.


If I choose peano's postulates.....then I end up with a type that N
obeys.

But what about implementation and the interface of a type? What you
describe looks rather as a set of provable propositions based on the type's
interface.

Yes.
The implementation is a seperate concern.
We can interpret the interface as just a language (set of signatures),
or as a type declaration.....I am happy to do either.
We happily reason about N every day, it would be pedantic to ask for
the implementation of N from ZFC, every time I work out my change at
the supermarket.


I don't see how it happens. If class does not change the type and object is
a member of class... is type_of transitive along member_of?

types of objects, no.

i.e. the integer 1 obeys the type

A = { "a == 1" }

Stop here. What is '=='? To me it is an operation defined on ... which
type?

in a sense it is well formed for all objects in the universe...though
some may not have it defined...for those the interpretation is *not*
true.

if I go

A = { "a.IsEqual(1)" }

does it make any difference?

It looks very much like a self-recursion. As a behaviorist, I don't
buy it anyway, because A is a subtype,

A is a subtype?.......

A is a set contraining a sentence with a free variable.

and you didn't present the base type
yet. Peano arithmetic is nice but it is not a type to me.


What is the type of N then?

As a side note, I'd say that what you are doing looks very close to the
relational approach to me. I think somebody from the RM camp could clarify
it.


I removed the cross post....thankfully...

My intepretation of type is a hair bredths different from Liskov/Wing,
in fact it's really there just put in terms of logic rather than
English.

Polymorphic object: (class, (type, value))

polymorphism to me is the substitution of a different
(implementation,value).

Before substitution you have to define "polymorphic object." Are all
objects polymorphic?

ummmmm.....yes....for the moment anyway.

Are true, 123, "a" polymorphic?

true is a member of the language, you are free to define a seperate
class 'boolean'...but it is *not* the same.....else stratification is
broken.

Yes! But I don't want stratification!

how do you avoid the barber, or Freges problem.

I allow the interface, but note no objects exist in any universe that
satisfy Russels paradox.
(note I haven't mentioned constructions, I don't need to, I can
establish this in the space of types.).

You could go the other way, and allow all interfaces if supplied with a
valid construction, but this seems onerous in programming, basically I
can't provavbly compile a library unless it is complete....perfectly
reasonable in a way


You have constructed some types which aren't Boolean. Let's talk about
bool. Let I change the first declaration to:

class Bool1 : public bool
{
bool IsBool1() { return true; }
...
};

Is true Bool1 and what does true.IsBool1() return?

according to that construction it is not defined....compile errror.

Same as above. I want to be able to derive from *any* type. If N is not
suitable for that, I don't care, because N is outside my language. It is
not a type. The language might provide some type int, or int32, or bignum,
which resembles N in some aspects. But it is not N. The gain is language
regularity. Every type is a type. For every type there is a class etc.


Your turn.....

What do you mean by "type" then.

.

Relevant Pages

  • Re: identity...... Was: The wisdom of the object mentors
    ... And what about construction of int? ... I construct all objects in the same manner.....(like a C++ compiler ... in mid air...I need a language, some axioms and some rules of ...
    (comp.object)
  • Re: identity...... Was: The wisdom of the object mentors
    ... construction mechanism.....for this I need to show a construction! ... And what about construction of int? ... polymorphism to me is the substitution of a different ... suitable for that, I don't care, because N is outside my language. ...
    (comp.object)
  • Re: identity...... Was: The wisdom of the object mentors
    ... construction mechanism.....for this I need to show a construction! ... And what about construction of int? ... polymorphism to me is the substitution of a different ... true is a member of the language, you are free to define a seperate ...
    (comp.object)
  • Re: Designing a Matrix class
    ... > Matrix(unsigned int m, unsigned int n); ... I realize I can write up the Matrix class from scratch, ... I can't see that part of the interface which gets you access to ... It will acquire space for several entries on construction (how much by ...
    (comp.lang.cpp)
  • Re: identity...... Was: The wisdom of the object mentors
    ... // this is it's implementation/mapping from a hidden domain of {int x int} ... I'd say that the set of all propositions is language defined behavior or ... Boolean object has no place to keep the class identity. ... bool IsBool1() ...
    (comp.object)