hattons@globalsymmetry.com ("Steven T. Hatton") wrote in message news:<-dmdnTHb8v5Vw43cRVn-pA@speakeasy.net>...
Steven T. Hatton wrote:
..
> It is a shame that the only way to really determine if a feature is
> valueable is to implement it in an environment where it can be well tested. And
> that seems to mean, make it part of the Specification.

If you mean it must be specified in the C++ standard, you're wrong.
First of all, that's not necessary; just include it as an extension to
a particular implementation of C++.  Secondly, that's not how it's
supposed to work. Adding a feature to the standard is a major step
that is very hard to reverse. You're not supposed to take that step
until after you've determined that the feature is valuable, preferably
by developing some real-world experience with it. You're not supposed
to add it to the standard in hopes of finding out that it will be
valueable.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

llewelly wrote:

> hattons@globalsymmetry.com ("Steven T. Hatton") writes:

>> Does anybody understand what I'm proposing?
>
> I think you are proposing an alternative to namespace-level functions
>     which help implement a class. I used to wish for such a feature
>     myself, but later I came to the opinion it was the result of a
>     misplaced desire to put everything associated with the class in
>     the class declaration. IOWs, my (now vanished) desire for the
>     feature did not come from a functional need, or a readbility
>     need.

I do believe the feature would potentially add value.  I'm just not sure how
much.  I don't believe the desire to put every thing associated with a
class in the class is misplaced.  If we consider a library, and/or codebase
to be a data store that is queried, either by human examination, or
programmatically, the explicit association of a function or other entity
with a class by making it a member provides more information to the query
mechanism than the implied association of putting the entity in the same
namespace.

>> Do you see any advantage to
>> such a feature?
>
> It seems trivial to simulate your proposed feature with
>     namespace-level functions.

I don't agree here.  It may seem that way at first, but my proposal is a
direct response to the use of namespaces to accomplish a comperable end.
In my mind the proposed associated specifier would promote cleaner, more
deterministice program design.

>> Is it worth further consideration?
> [snip]
>
> I think the time and energy necessary for it would be better spent on
>     any of a number of other potential extensions.

Give me a better exception mechanism than the one I have, and obviate the
preprocessor, and I will be very happy.  Much happier than merely getting
the associated access specifier would make me.

I will say that every feature I want added to C++ seems to boil down to
being able to determine what resources are available in a give context
(scope), and where the available resources came from.

C++ is a significantly more complex language than Java.  That means it is
more difficult to learn and in some ways to work with.  The big advantage
Java offers me which I really wish I had in C++ is the very coherent way
different components present themselves to the programmer (or IDE -
<pounding fist on podium>).  This is more basic than
reflection/introspection.  The most fundamental aspect of what I am
reffering to is what I've begun calling a /signature list/, or /class
signature/.  In a word, javap.

I can look at the output of javap run against any Java class, and see the
available methods (member functions) along with all the arguments, return
values, exceptions thrown, access specification, etc.  The absences of this
kind of coherence in C++ adds to the comparative difficulty in using the
language.  If that situation can be addressed in C++, the programmer can
focus on leveraging the strengths of the language, rather than overcoming
the weaknesses.

I can design my C++ programs so that much of this kind of information is
available in interface ABCs, or at least in header files, but I can't rely
on the libraries I use to do this, nor to do it in a way consistent with
what others have done.

Perhaps the horse is already out of the barn on this one, but if there is a
way to make C++ code more deterministic as a data store by modifying the
Standard, and the cost isn't too high, it should be done.

> On the other hand, maybe you'll discover a crucial use which isn't
>     easily handled by current semantics. However I don't thinnk that
>     is likely.

It is a shame that the only way to really determine if a feature is
valueable is to implement it in an environment where it can be well tested.
And that seems to mean, make it part of the Specification.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:

> llewelly wrote:
>
>> hattons@globalsymmetry.com ("Steven T. Hatton") writes:
>
>>> Does anybody understand what I'm proposing?
>>
>> I think you are proposing an alternative to namespace-level functions
>>     which help implement a class. I used to wish for such a feature
>>     myself, but later I came to the opinion it was the result of a
>>     misplaced desire to put everything associated with the class in
>>     the class declaration. IOWs, my (now vanished) desire for the
>>     feature did not come from a functional need, or a readbility
>>     need.
>
> I do believe the feature would potentially add value.  I'm just not sure
> how
> much.  I don't believe the desire to put every thing associated with a
> class in the class is misplaced.  If we consider a library, and/or
> codebase to be a data store that is queried, either by human examination,
> or programmatically, the explicit association of a function or other
> entity with a class by making it a member provides more information to the
> query mechanism than the implied association of putting the entity in the
> same namespace.

I have to acknowledge the following from TC++PL(SE) page 128 "Conversely, if
implicit type conversion is desired for all operands of an operation, the
function implementing it must be a nonmember function taking a /const/
reference argument or a non-reference argument"

Unless that situation can be addressed (which is conceivable) there would
still be a valid reason for having non-member, namespace-local functions.
Following the above statement Stroustrup goes on to say that these are good
candidates for /friend/s.  I have yet to be convinced that /friend/ is
really a good idea.  I certainly avoid it by providing accessor methods on
the operands.  Since these are binary operators which do not modify the
operands, it seem to violate his advice not to rely on unnecessary direct
access to the private or protected members of a class.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Below is the text of a previous post to this group.  I'm not sure anybody
has given this enough consideration to actually understand it. The concep=
t
returns to my mind quite often when writing C++ code. Associated members =
of
a class would serve the same purpose as what are currently implemented as
namespace-local 'helper' functions. I believe what I'm talking about are
basically static members which lack access to protected and private membe=
rs
of the class. I'm not sure what it would mean for variables to be
'associated'.

One example of how such a specifier might be used is to provide a utility
base class. This base class would provide member functions which don't ne=
ed
access to the implementation, but are relevant to all classes derived fro=
m
it.

Does anybody understand what I'm proposing?  Do you see any advantage to
such a feature?  Is it worth further consideration?

Previous post:
In another context I proposed the introduction of a new access specifier.
The word I used was associated.=A0=A0The=A0intended=A0meaning=A0is=A0that
an associated member is inextricably connected to the class, but does not
have reason or ability to access private or protected members.=A0=A0My
motivation was to find a compromise between my desire for
compartmentalization, and Stroustrup's reasoning that some 'helper'
functions don't need private or protected access to class members. The
following from TC++PL(SE) explains the reasoning:

"Typically, a class has a number of functions associated with it that nee=
d
not be defined=A0=A0in=A0the=A0class=A0itself=A0because=A0they=A0don't=A0=
need=A0direct=A0access
to the representation. For example:

=A0=A0int=A0dif(Date=A0a,=A0Date=A0b);=A0//=A0number=A0of=A0days=A0in=A0t=
he=A0range=A0[a,b)=A0or=A0[b,a)
=A0=A0bool=A0leapyear(int=A0y);
=A0=A0Date=A0next_weekday(Date=A0d);
=A0=A0Date=A0next_Saturday(Date=A0d);

"Defining such functions in the class itself would complicate the class
interface and increase the number of functions that would potentially nee=
d
to be examined when a change to the representation was considered.

"How are such functions "associated" with the class /Date/? Traditionally=
,
their declarations were simply placed in the same file as the declaration
of class Date, and users who need /Date/s would make them all available b=
y
including the file that defined the interface (9.2.1). For example:

#include "Date.h"

"In additions to using a specific Date.h header, or as an alternative, we
can make the association explicit by enclosing the class and its helper
functions in a namespace:

=A0=A0namespace=A0Khrono{=A0//=A0facilities=A0for=A0dealing=A0with=A0time
=A0=A0=A0=A0class=A0Date{/*...*/};
=A0=A0=A0=A0int=A0dif(Date=A0a,=A0Date=A0b);=A0//=A0number=A0of=A0days=A0=
in=A0the=A0range=A0[a,b)=A0or=A0[b,a)
=A0=A0=A0=A0bool=A0leapyear(int=A0y);
=A0=A0=A0=A0Date=A0next_weekday(Date=A0d);
=A0=A0=A0=A0Date=A0next_Saturday(Date=A0d);
=A0=A0=A0=A0//...
=A0=A0}

"The Khrono namespace would naturally also contain related classes, such =
as
Time and Stopwatch, and their helper functions."
//-----------------------------------------//

To my mind the argument regarding the complexity of the interface is
misplaced.=A0=A0Now=A0we=A0have=A0a=A0namespace=A0with=A0an=A0'interface'=
=A0which=A0has=A0classes
and functions.=A0=A0Some=A0of=A0the=A0functions=A0may=A0or=A0may=A0not=A0=
be=A0related=A0to=A0Date=A0or
other classes.=A0=A0If=A0we=A0wish=A0to=A0extract=A0Date,=A0or=A0some=A0o=
ther=A0class,=A0from=A0the
namespace, we are again revisited by the problem of considering which
functions are involved.

If the functions could be bound to the class(es) they are associated with=
,
there would be more clarity in their purpose, refactoring would be easier=
,
namespaces would be more orderly, IDE's could provide more complete
information about the facilities associated with a given class, etc.

It was for this reason I proposed the associated access specifier.=A0=A0T=
he
more I think about this, the more reasonable it seems to me.=A0=A0There=A0=
are
many unanswered questions such as how they would be inherited, whether th=
ey
would all be static (if that matters), etc.

I'm interested to know what other's think about this idea.
--=20
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hattons@globalsymmetry.com ("Steven T. Hatton") writes:

> Below is the text of a previous post to this group.  I'm not sure anybody
> has given this enough consideration to actually understand it. The concept
> returns to my mind quite often when writing C++ code. Associated members of
> a class would serve the same purpose as what are currently implemented as
> namespace-local 'helper' functions. I believe what I'm talking about are
> basically static members which lack access to protected and private members
> of the class. I'm not sure what it would mean for variables to be
> 'associated'.
>
> One example of how such a specifier might be used is to provide a utility
> base class. This base class would provide member functions which don't need
> access to the implementation, but are relevant to all classes derived from
> it.
>
> Does anybody understand what I'm proposing?

I think you are proposing an alternative to namespace-level functions
    which help implement a class. I used to wish for such a feature
    myself, but later I came to the opinion it was the result of a
    misplaced desire to put everything associated with the class in
    the class declaration. IOWs, my (now vanished) desire for the
    feature did not come from a functional need, or a readbility
    need.

> Do you see any advantage to
> such a feature?

It seems trivial to simulate your proposed feature with
    namespace-level functions.

> Is it worth further consideration?
[snip]

I think the time and energy necessary for it would be better spent on
    any of a number of other potential extensions.

On the other hand, maybe you'll discover a crucial use which isn't
    easily handled by current semantics. However I don't thinnk that
    is likely.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]