Re: Self pointer in limited record

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 06 Sep 2007 09:19:54 +0200, Jean-Pierre Rosen wrote:

> Dmitry A. Kazakov a �crit :
>>> 2 certainly can. The idea is that you cannot put "Spike the dog" into 
>>> your computer; what you can do is put some characteristics of it in the 
>>> form of data that are of interest from the point of view of your 
>>> program. You therefore abstract away all the uninteresting properties.
>> 
>> Yes, but my point is that these characteristics would have qualitative or
>> quantitative values from some sets. For example weight. Can I change it?
>> Would it be Spike? If yes, then what does the weight characterize? 
> Of course, if I feed Spike too much, its weight will change - and it is 
> still Spike. I don't see the problem here.

You don't need to model Spike's weight in your system because changing the
weight should have no effect. Spike cannot communicate its weight to other
components of the system, because it is not *a* thing with mass. No, it is
just Spike, the One. Its weight has been abstracted away.

>> If not,
>> where is Spike? As long as I can construct (not Spike), it is not unique.

> But if, *for my problem*, I am interested only in Spike, (not Spike) 
> makes no sense.

It might make no [immediate] use, but it does sense in the context of your
abstract model. Some properties of Spike cannot be abstracted away even if
they might happen to be constant/uninteresting. So your model is capable to
deal with objects of different weight. It would certain generalization
power. This can be used in order to verify consistency or ease
implementation.

Weight is a number with all properties of real values + ones of mass,
acceleration etc. But Spike's weight (tm) is not a number. It is another
singleton specific to Spike and unrelated to anything else = nothing.

> I'm not arguing that there cannot be a class of dogs, 
> but that if in my problem domain I am interested in the properties of a 
> single object, I can represent that single object in a computer, and 
> that the representation of this single object, because it omits all the 
> details that are not relevant to my problem, is an *abstraction*.

That's OK. I don't argue that there shall be multiple instances. However
this too might potentially be quite useful in order to allow the compiler
to pass Spike by value, to put it in a register or cache, to marshal over
the network. Why should I care? In most [not all] cases I need not.

Then to me, property/attribute/characteristic = a primitive operation
yielding a value of some [other] type. How something without a type can
have a primitive operation in a typed language like Ada?

>>> How could you have something in the model that is not in what you are 
>>> modelling?
>> 
>> I can add some properties to make implementation simpler or possible. 
> Ha! You said "implementation". To me, that's the concrete view. The 
> abstract view is there to hide implementation details.

I meant implementation in a broader sense than "private constructs." Public
declarations is an implementation too. Maybe, "realization" or "spelling"
would be better.

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