--94eb2c0b7ca0b6c91b0524ebffd5
Content-Type: text/plain; charset=UTF-8

I am posting this as a new thread because I do not want to undermine the
ongoing discussion of what I will term the "namespace class" proposal.

Assuming that proposal is successful I see opportunity to address another
C++ rough edge.  As in the former proposal this adds no actual new
functionality to C++ but it would make it more pleasant to use.  (In some
respects this is a less ambitious, less complex attack on the usage sweet
spot that the various Uniform Call Syntax proposals seem to address.)

A tension I have encountered repeatedly (and resolve differently on
different occasions) is the requirement to make a function a class member
in-order to confer upon it method invocation syntax.

When I implement an abstraction I start with a base set of methods that can
only be implemented as true class members (*i.e.* they require access to
the class' internals).  Often after that I have an additional set of
services, wrappers, what-have-you that I want to present as part of how a
client should think about the class even though they all can be implemented
entirely in terms my earlier base methods.  Ideally I want my users to use
method invocation syntax to call operations in this second set.  And indeed
I can achieve that by including those operations in the class definition.
Often though that seems a high price to pay merely to achieve syntactic
uniformity.

Already today a classic namespace need not be defined all at once.
Disparate sites can open the same namespace in order to add entries.  I
would like to suggest that "namespace class" have a similar behavior:

   - If a "namespace class" function definition has a signature that
   matches a method within the corresponding class still missing a definition
   then it "completes" that method.
   - Otherwise such a"namespace class" function becomes a member of the
   namespace class (but not the class).  It must be called using method
   invocation syntax.  Its implementation can use unqualified naming to refer
   to public members of the clas.  OTOH it is granted no special access (it is
   restricted to exploiting the public interface).
   - No virtual nor static functions.
   - No data (neither static nor instance).

A const method qualifier should be allowed with the obvious semantics.

/john

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--94eb2c0b7ca0b6c91b0524ebffd5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I am posting this as a new thread because I do not want to=
 undermine the ongoing discussion of what I will term the &quot;namespace c=
lass&quot; proposal.<div><br></div><div>Assuming that proposal is successfu=
l I see opportunity to address another C++ rough edge.=C2=A0 As in the form=
er proposal this adds no actual new functionality to C++ but it would make =
it more pleasant to use. =C2=A0(In some respects this is a less ambitious, =
less complex attack on the usage sweet spot that the various Uniform Call S=
yntax proposals seem to address.)</div><div><br></div><div>A tension I have=
 encountered repeatedly (and resolve differently on different occasions) is=
 the requirement to make a function a class member in-order to confer upon =
it method invocation syntax.</div><div><br></div><div>When I implement an a=
bstraction I start with a base set of methods that can only be implemented =
as true class members (<i>i.e.</i>=C2=A0they require access to the class&#3=
9; internals).=C2=A0 Often after that I have an additional set of services,=
 wrappers, what-have-you that I want to present as part of how a client sho=
uld think about the class even though they all can be implemented entirely =
in terms my earlier base methods.=C2=A0 Ideally I want my users to use meth=
od invocation syntax to call operations in this second set.=C2=A0 And indee=
d I can achieve that by including those operations in the class definition.=
=C2=A0 Often though that seems a high price to pay merely to achieve syntac=
tic uniformity.</div><div><br></div><div>Already today a classic namespace =
need not be defined all at once.=C2=A0 Disparate sites can open the same na=
mespace in order to add entries.=C2=A0 I would like to suggest that &quot;n=
amespace class&quot; have a similar behavior:<br></div><div><ul><li>If a &q=
uot;namespace class&quot; function definition has a signature that matches =
a method within the corresponding class still missing a definition then it =
&quot;completes&quot; that method.</li><li>Otherwise such a&quot;namespace =
class&quot; function becomes a member of the namespace class (but not the c=
lass).=C2=A0 It must be called using method invocation syntax.=C2=A0 Its im=
plementation can use unqualified naming to refer to public members of the c=
las.=C2=A0 OTOH it is granted no special access (it is restricted to exploi=
ting the public interface).</li><li>No virtual nor static functions.</li><l=
i>No data (neither static nor instance).</li></ul><div>A const method quali=
fier should be allowed with the obvious semantics.</div></div><div><br></di=
v><div>/john</div><div><br></div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--94eb2c0b7ca0b6c91b0524ebffd5--

.