On Thu, 24 Jul 2008 12:20:07 +0200, Georg Bauhaus wrote:
> Dmitry A. Kazakov wrote:
>>>> then in 80s, but it is no any problem now. IDEs do it better.
>>> Ada IDEs cannot affect semantics?
>>
>> I am not sure what you mean... GPS does affect the semantics when you
>> change some project options.
>
> I meant the semantics of child packages and separate units
> as given in the program text.
I lost your point. Can you elaborate it a bit more?
Just to remember, mine was that separate bodies were often used to
structure the source code in order to make it more maintainable and
readable. IDEs and tools are better suited for that. Another use I can
recollect was stubs [in top-down structured programming]. Unfortunately it
never really worked. Today we are using abstract primitive operations
instead.
>>> But suppose your implementation includes one subprogram,
>>> procedure A(... : T; ...);
>>> that provides for one aspect of the solution made with T.
>>> If that one aspect depends on packages P3 and P4, but A is the
>>> only supbrogram in your package that depends on P3 or P4,
>>> why create another child just for this one aspect?
>>
>> Which is exactly the problem. "Just one aspect" is an improper way of
>> problem decomposition.
>
> Why, e.g., build an entire type when a single procedure
> is sufficient, and will be sufficient in the future?
How can you know that?
> It is possible to think of a procedure (or function etc.) as an
> abstract state machine.
Hmm, it is almost impossible.
Procedures describe transitions between states encapsulated by the
parameters and the results of (only the latter in pure functional
languages).
> Many languages have a function type
> built in, functions are objects.
But not in the sense of a stateful object of OO. They are language objects
(a completely unrelated thing, except that in an OOPL a stateful object is
a language object.).
>> 3. The "aspects" available for "separation" are often low level. Your
>> example nicely illustrates this point. It is a pure low-level
procedural
>> decomposition.
>
> OK but this shows very little. Without a procedure (as in "procedural
> decomposition"), a program does nothing. Should every procedure
> be a primitive operation?
Yep, very much so.
> This question is IMO worth asking
> when the task at hand is not "the general theory of problem
> decomposition using ADTs" but "how to write this specific program".
I was always wondering people saying such things. Yes, you can drive the
wrong side of the road so long there is no police officer watching you.
> There is a trade-off:
Really?
> Another ADT child package could become more
> general but introduces complexity. Artificial complexity as,
> I'm sure, some will say.
Well, well, Ada is complex, C is good. Why do you need that artificial
complexity. Everything is void * etc...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
|
