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


Dmitry A. Kazakov wrote:
On 9 Jun 2006 08:03:03 -0700, Mark Nicholls wrote:

Ah, identity lies in construction. So 2DVector does not have it, the
construction does. (:-)) And what about construction of int?

I construct all objects in the same manner.....(like a C++ compiler
does when talking about 'this').

It's much easier for me to just map state out to the client....then
identity only exists as a sequence of operations on variables being
assigned to variables.....i.e. idenity would then not be a
construction, but an observation on a program.

I am only trying to demonstrate my feeling about "identity" being
similar to my feeling about "this".......I can't actually write a C++
compiler!

I can, but that does make things any easier, at least to me. Consider the
following, let you have to write a family of compilers, like GCC, but the
requirement is that unlikely to GCC, they all would have the same
front-end. The difference would be in the knowledge base used for the given
language. Lexically and syntactically it is no problem. The problem is in
the semantics of the constructs. What is "class", what is "type" etc.

To much undefined things. GetState(), SetState, operator [], operator =.
Identity is just a name. As I said it is an artefact of prefix notation.
Consider *same*:

type 2DVector is ...
procedure SetYCoord (Object : in out 2DVector; Coord : Integer) is
begin
Object.Y := Coord;
end SetYCoord;

So much for identity. Object is a variable, so your "Identity". That's all.

exactly!

it is a path through a tree of states of variables in a program.

most people hide 'this' though.

I am simply saying my concept of identity is akin to the concept of
this.

But then it is just identity of the name. You give a name to some thing and
promise that name->thing is a mapping. Your promise cannot be proved or
tested. It is outside the scope.

actually I think you could map a program defined in terms of fixed
value (can't remember the word) 'objects'....into a program with
volatile objects...in that sense 'this' does not exist....or at least
need not exist...in a single threaded world.

But yes I agree....but I need some axioms/construcions, I cannot build
in mid air...I need a language, some axioms and some rules of
derivation....ironically I think object and identity are two things I
do not need as axioms.

All that I wished to say that (name,thing)
has identity and the identity is name, while thing alone does not have it.

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?

Hmm, IsEqual () is a sugar for == (a, 1).

yes

in most OO languages we would write it like this, I can if you like
write in functions.

But the problem is that == is not defined yet on A. To put it otherwise, is
your language typed?

If I have a language/s, currently it is logic, predicate logic.....so
no. It is not typed.

If it is, you have to start with an axiom that no
operation of a type X can applied to the type Y, when X isn't Y (types
identity needed here).

It's not 'typed'....'==' is a relation defined on the universe.....all
functions are defined on the universe.....it fits more closely to the
classical approach.

So there is == of int and == of A. Inheritance is a
way to get A::== from int::==. To me it is equivalent to subtyping. To you,
well, I don't see how you first get out of the problem of bad recursion
between types and operations of.

you are using your definition of type....I have never said operations
are defined on 'types'.....types are descriptive to me....not
constructive....operations are defined on interfaces (languages)....for
a sentence to be well formed, it cannot use functions/relations that
are not defined in the language (union of the interface definitions).

in logical terms the type of 'string' in a universe containing
something that supports sqrt, could include a sentence

"there does not exist an A s.t. A = sqrt(B)".



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

Yes, how otherwise you'd be able to apply == of int to the values of A?

just because an class implement '==' does not necessarily mean it is a
subtype of another class that implements '=='.

they will trivially be subtypes of the type.

{ "a == a OR NOT a == a" }

there is nothing special about '=='.

Special is that you presume anything about it for all a's, without
specifying the types of a's.

I'm taking IsEqual to be a relation defined over the universe.

To me it's a not a question of types as such, but a question about what
makes a well formed sentence....we can introduce domains and codomains
later.


Operations and relations are defined independently and apply to all
objects in the universe....thus my reticence about '==' being defined
univerally.

I.e. it is untyped.

yes.


What do you mean by "type" then.

At least the set of values + and the set of operations. Though it looks
much like the interface of. Maybe one should add the implementation of.

OK, but then it seems to be everything....what I would call a
model....I think.

Model should be a set of types and objects of.

actually this definition works for both of us......it just means
different things to each of us!

I think we may have clobbered this one to death.

.

Relevant Pages

  • Re: identity...... Was: The wisdom of the object mentors
    ... // this is it's implementation/mapping from a hidden domain of {int x int} ... construction mechanism.....for this I need to show a construction! ... I'd say that the set of all propositions is language defined behavior or ... But what about implementation and the interface of a type? ...
    (comp.object)
  • Re: [CodeGallery] MFC MD5 Calculator
    ... Then when they added types, internally, the compiler still thought they were int values, ... ANSI standard began to emerge that the language design ...
    (microsoft.public.vc.mfc)
  • OT: Re: Perl Peeves
    ... I see the result of a test being used as an int. ... the compiler just assumed you knew what you were doing ... introduced to the language later, so void * was unheard of in most code. ... This didn't mean bool was special, declaring it just signaled to the ...
    (comp.lang.perl.misc)
  • Re: First steps on overloading
    ... where the operand manipulation code is located, ... very many additions and changes to the language semantics. ... Allowing int + date, as well as date + int (although the former seems a bit ... compiler would reorder the operands. ...
    (comp.lang.misc)
  • 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)