Re: another way to shoot yourself in the foot?

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

On Wed, 25 Jun 2008 12:32:05 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
> 
>>> And now automatic operations like Initialize and Finalize,
>>> hooked on a single type (and possibly discriminants---does
>>> GNAT like at last :-) are supposed to be the solution of
>>> all data management?
>> 
>> Yes they are. Note that constructing/destructing hooks have different rules
>> of composition, like aggregates and assignments have. They are not
>> overridden they are extended. (Ada's Finalization is bogus, alas).
> 
> Just one point ad hoc.
> Taking the notion of construction further, define the concept
> of initialization.
> 
> In general, initialization of an object Obj_1 of type T1
> may logically be related to the observable state of Obj_2
> of type T2, where observable state means result of operations
> or (component) values. As these states change while a
> program is running, the dependences may not always be the same.
> 
> Obj_1's initialization may logically depend on
> 
>    F(Obj_1, ..., Obj_N),
> 
> or more generally on
> 
>    F(G_1(Obj_1_1, ..., Obj_M_1), ... G_J(Obj_1_J, ..., Obj_M_J)).
> 
> for some finite sets of objects and functions.
> Basically, on anything that can be programmed into an expression
> used for initializing. It may be cross unit, involve P98.T19 or not,
> or A.B.T42 only if G_17(Obj_127) > 666 etc.
> 
> This "net of dependence" would mean that a constructor will have
> to adjust its behavior to the current state of the program. Adjustment
> may be realized through dispatching to a load of objects, other
> constructors, etc. etc. etc.  IOW, every constructor becomes a huge
> factory in disguise.  It has to perform case distinction.
> How is this seemingly special construction different from just
> normal programming?  The only added value of constructors that
> I can see is that I can point to a few functions which "point to"
> all this. A good addition, and not a small one. But should we
> therefore abandon all other means of initializing things?
> 
> If construction turns out to be mostly normal programming, why
> not use plain old language features in addition to specialized
> constructor programming? For example, use local scopes and
> visibility for providing (computed) initial values, even though
> a scope is not an operation of a type, like a construtor function
> is.

Because of. Information hiding. You want to promote the object as an opaque
abstract type. It is the type which is responsible for object construction.
It is just not the user's business. This is a pragmatic argument of
avoiding a huge distributed overhead of proper initialization of all
instances the given type might ever have. It is a maintenance disaster if
something gets changed.

The theoretical argument is that initialization is not equivalent to
construction. Well, it is, when types are ignored. But types does not exist
at run-time anyway. Type is an abstraction used to annotate untyped machine
code. So while the machine code might appear same, semantically it is
different [*]. Now, within a typed framework, the constructor cannot be
decomposed into subprograms, it fundamentally cannot. There is no way to
convert raw junk of bits into the same bits having the meaning of an object
of the given type.

------------
* The simplest way to illustrate this in Ada is:

   type Int is new Integer; -- The code will be same

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