Re: Self pointer in limited record

[Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de>]

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?

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

(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!)


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


> For dynamic scoping there exit blocks. We cannot replace blocks by
> packages. So let blocks rule. The only possible reason for nested packages
> is the language regularity: if a package can be nested in another package,
> then it should be allowed in any declarative scope. Probably even between
> "for" and "loop"! (:-)) But if you removed nested packages altogether you
> would  probably notice no miss. Because it is only static nesting which is
> really needed, and that is covered by the child packages.

Well, so what?
Can I use a package declared within a procedure as a match for a
problem domain object? 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.