In article <347395$fp7@hpsystem1.informatik.tu-muenchen.de>,
schuenem@Informatik.TU-Muenchen.DE (Ulf Schuenemann) writes:
|>
|> template <class T, int size>
|> namespace Collection
|> {
|>  ...
|>  Collection& foo(...)
|>  {
|>   here goes the code
|>  }
|>  typedef int Bar;
|>  Bar data = 12;
|>  Bar fun ()  { ... }
|> };
|> One question remains: what about the definition of identifiers
|> that have not been declared within the class ? How to conform
|> with the one-definition-rule and to encapsulation (note:
|> they can be added anywhere/by anybody to namespace X) ?
|>
|> a) it's an error
|> b) these new defitions are
|>   - not members of the class: to keep encapsulation
|>   - private: to keep one-definition-rule of the class X
|>     (X::data is not accessable, only static members of _class_ X
are)
|>
|> With b) follows that the new definitions can _only_ be used for the
|> implementation of the class. This would be a step towards
|> SEPARATION OF IMPLEMENTATION FROM INTERFACE. Everybody who wants
|> this, please support "implementation Class"/"namespace Class".
|>

It happened already a few times to me that during the implementation
of a member function in the .c file I introduced an auxiliary function
(which was sometimes even useful for several member functions).
There was always this dilemma of
1) defining the auxiliary function at file scope
   (not always possible if you need access to data members)
2) "reopening" the class definition and putting it as
   a private member function there.
I think that suggestion b) offers a good solution to this dilemma.

I don't see any problems for private non-virtual member functions
added this way. Adding data members and virtual member functions
is more difficult. Even if the compilers can be made clever enough
to deal with this problem, I consider it very useful (even necessary)
that the same technique would work also for *online* replacement of
translation units.

|> Ulf Schuenemann
|>
|> --------------------------------------------------------------------
|> Ulf Sch   nemann
|> Institut f   r Informatik, Technische Universit   t M   nchen.
|> email: schuenem@informatik.tu-muenchen.de
|>


-----------------------------------------------------------------------
Johan Vanslembrouck - SE99            Tel    : +32 3 2407739
Alcatel Bell Telephone                Telex  : 72128 Bella B
Francis Wellesplein  1                Fax    : +32 3 2409932
B-2018 Antwerp                        e-mail : jvsb@sebb.bel.alcatel.be
Belgium
-----------------------------------------------------------------------

Recall the first time you saw the definition of a non-inline member
function:

void Class::foo(...)
{
}

I still remember this looked rather ugly to me. Especially when
you have a rather large number of relatively small member functions,
the explicit scoping is rather disturbing.

Things are much worse when using templates. There you can find monsters like:

template <class T, int size)
Collection<T,size)& Collection<T,size>::foo(...)
{
}

It's becoming difficult to separate the meaningful information from
the information just needed by the compiler - to see the wood from the trees.
If you want to tell managers why you prefer C++ over language X, then
I advise you not to use the example above. It's more an example
adversaries of C++ can use to show how *ugly* the language is.

What about the introduction of a keyword "implementation" similar
to "class" or "struct". Then you can write

in the .h file (as usual):

template <class T, int size>
class Collection : public ABaseClass
{
 ...
 Collection& foo(...);
 ...
};

and in the .c file:

template <class T, int size>
implementation Collection
{
 ...
 Collection& foo(...)
 {
  here goes the code
 }
 ...
};

It's much easier to read, isn't it ?
There can be many implementation blocks per class or struct.

Another advantage of my proposal is the possibility to move code
in an easy way from the class section to the implementation section
and vice-versa.
There is no need
   1) to add or remove the scoping operator
   2) to change the indentation from one leading tab in the class
      to no spaces in the implementation (this is the way most code is
      indented)

Of course, the current syntax with explicit scoping remains supported.


-----------------------------------------------------------------------
Johan Vanslembrouck - SE99            Tel    : +32 3 2407739
Alcatel Bell Telephone                Telex  : 72128 Bella B
Francis Wellesplein  1                Fax    : +32 3 2409932
B-2018 Antwerp                        e-mail : jvsb@sebb.bel.alcatel.be
Belgium
-----------------------------------------------------------------------

In article <1994Sep1.083628@sebb.bel.alcatel.be>, jvsb@sebb.bel.alcatel.be (Johan Vanslembrouck) writes:
|> [...]
|> Things are much worse when using templates. There you can find monsters like:
|>
|> template <class T, int size)
|> Collection<T,size)& Collection<T,size>::foo(...)
|> {
|> }
|>
|> It's becoming difficult to separate the meaningful information from
|> the information just needed by the compiler - to see the wood from the trees.
|> If you want to tell managers why you prefer C++ over language X, then
|> I advise you not to use the example above. It's more an example
|> adversaries of C++ can use to show how *ugly* the language is.
|>
|> What about the introduction of a keyword "implementation" similar
|> to "class" or "struct". Then you can write
|> [...]
|> and in the .c file:
|>
|> template <class T, int size>
|> implementation Collection
|> {
|>  ...
|>  Collection& foo(...)
|>  {
|>   here goes the code
|>  }
|>  ...
|> };
|>
|> It's much easier to read, isn't it ?
|> There can be many implementation blocks per class or struct.
|> [...]

Ideas like this have already come up in this newsgroup.
[I've just noticed that there's right now another article #10054
 proposing "implementation" in a similar way:
From: jasonoz@cairo.anu.edu.au (Jason Ozolins)
Subject: an extension idea that someone else might even like   :-)
]
E.g. using the keyword "namespace" as "implementation" coz it's a way
of reopening the namespace of the class (i.e. avoiding explicit
scoping not only for the methodname but also for types etc. declared
within the class) and the namespace of a X can be broken into
many "namespace X { }". But there was only little support for
this idea.

template <class T, int size>
namespace Collection
{
 ...
 Collection& foo(...)
 {
  here goes the code
 }
 typedef int Bar;
 Bar data = 12;
 Bar fun ()  { ... }
};
One question remains: what about the definition of identifiers
that have not been declared within the class ? How to conform
with the one-definition-rule and to encapsulation (note:
they can be added anywhere/by anybody to namespace X) ?

a) it's an error
b) these new defitions are
  - not members of the class: to keep encapsulation
  - private: to keep one-definition-rule of the class X
    (X::data is not accessable, only static members of _class_ X are)

With b) follows that the new definitions can _only_ be used for the
implementation of the class. This would be a step towards
SEPARATION OF IMPLEMENTATION FROM INTERFACE. Everybody who wants
this, please support "implementation Class"/"namespace Class".


Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch   nemann
Institut f   r Informatik, Technische Universit   t M   nchen.
email: schuenem@informatik.tu-muenchen.de