Re: The old "Object.Method" syntax debate

[john@nospam.demon.co.uk (John McCabe)]

On Tue, 3 Jun 2003 19:23:55 +0200, Lionel.DRAGHI@fr.thalesgroup.com
wrote:

>| That is a fair point, but it would be interesting to know how much of
>| the Ada code written in under the 'object-oriented' paradigm actually
>| uses a single tagged type per package. Over a period of around 3 years
>| I worked in 2 separate companies where this was pretty much the case.
>| In fact, in both cases the code structure was automatically generated.

>I don't think it's a good practice. I find awkward to create create a child
>for a class that perfectly fit in the same package.

I don't really understand what you mean there.

>Simple coding rules are good, but enforcing one class per package (and
>calling it always "Object", or "Class") just bring Ada down to other
>langages that do not have a strong modularity support and use classes for
>this purpose.
>Scattering strongly coupled classes on many packages lower readability. 

>And there is always a better name than "Object" or "Class". 
>Similarly, calling a formal "This" is, i think, a bad practice, there is
>always a better name.

>Automatically generated code often lead to this, not only because it
>simplify the code generator, but because tools (and UML) do not provide
>serious support for Ada modularity. 
>Most tools don't care, they just target C++ or Java, and so are mainly
>"class translator".

I agree to some extent with what you say here but, in the first
company I mentioned the code generator was an in-house design written
in Ada that used the output of [insert design tool name here :-)]
generate the code. Although I said there was one tagged type per
package, thinking back on it that wasn't quite true. The effect was
something like that but there was a main tagged type relating to the
actual functionality required, and a couple of tagged types relating
to the overall structure and scheduling mechanisms (queues etc - tasks
weren't used). In the second company I mentioned we used Rational Rose
(UML). In this case we configured the tool to produce reaonable object
and class names based on the classes we created. Having read a number
of articles about using "Object" and "Class", as well as listening to
a number of reasons from other team members why this was a daft idea,
it was decided not to pursue that convention.

Ultimately the "one tagged-type per class" mechanism wasn't
'enforced', but most of the packages came down to that and maintenance
(with a couple of hundred packages) was fairly straightforward.


Best Regards
John McCabe

To reply by email replace 'nospam' with 'assen'