Re: Self pointer in limited record

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

On Mon, 03 Sep 2007 22:38:49 +0200, Georg Bauhaus wrote:

> On Mon, 2007-09-03 at 16:17 +0200, Dmitry A. Kazakov wrote:
>> On Mon, 03 Sep 2007 12:51:14 +0200, Georg Bauhaus wrote:
>> 
>>> On Mon, 2007-09-03 at 09:53 +0200, Dmitry A. Kazakov wrote:
>>>> On Sun, 02 Sep 2007 23:37:33 +0200, Georg Bauhaus wrote:
>>>> 
>>>>> Suppose every package is reusable.
>>>> 
>>>> That's the goal.
>>> 
>>> Why?
>> 
>> In order to get a better understanding of the problem and solution.
> 
> What, exactly, is the improvement in understanding
> a given problem that involves one House and one Barn? The fact
> that by way of scholastic sophistication we can think
> of all kinds of combinations of many Barns, or Houses?
> What is the gain in coming up with types summarizing
> things that just are not present in the problem domain?

Wow, are you arguing against understanding or just against reuse and
refactoring (used in order to achieve it)?

> Should we have to rewrite the descriptions of our models
> until the goal of achieving all-package-reusability
> can be reached?

Yes, this is a part of normal software developing / evolving cycle. Or do
you have write-once applications in mind?

> (I know that programming just a little more than what is
> necessary for solving the given problem can be beneficial.
> The solution may gradually become much less simple, though.
> Difficult to understand, that is!)

Abstraction, normally reduces, complexity, provided that a better
understanding was indeed achieved...

>>> The "abstract state machines" kind of package (as opposed
>>> to those packages framing an "abstract data type") do work well
>>> in Ada program without a type parameter; it doesn't carry
>>> any additional information of spectacular use.
>> 
>> It is difficult to see how an abstract state machine is not a type.
> 
> Ada type or DK type?
> Certainly packages can have seen to have "qualities" that Ada
> types happen to have as well, e.g. exposing an "interface" in
> the non-Ada sense of the word. A singleton will have this kind of
> interface. A type defined in the corresponding package changes
> little in this regard.

I don't follow you. There are five things, all different:

1. Abstract data type
2. Package
3. Singleton
4. State machine
5. Abstract state machine

I don't see why you take for granted that 2 = 4 or 5. Package is not a
state machine, at least if you don't want to reduce everything to machine
code. Even less is it an abstract state machine.

> Can I use a package declared within a procedure as a match for a
> problem domain object?

Packages are not for modeling individual objects.

> It seems quite reasonable to me to do so
> when a local package is an easy way to deal with lifetime,
> modularization, and visibility at the same time.

Nonsense. When you want to use a package as a model of something, then all
your words about lifetime, modularization, being local etc become
meaningless. These are solution-specific properties irrelevant to the thing
being modeled. You have to talk about the domain problem properties. Which
properties of the domain are modeled by a package? Solve at least one
*domain* problem using a package, only package and nothing but package.
See?

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