🚀 go-pugleaf

In article <9508170857.ZM22058@jabba>, Ajay Kamdar <ajay@lehman.com> wrote:
>Given a multimap, this is what I would have *liked* to do:
>
>    multimap<int,double> m;
>    m.insert(3, 5.0);
>
>But of course, such a function does not exist. Is there a reason why
>STL opted not to provide this convenient interface and chose to go
>with the more tedious (for the user) approach of insert taking
>a pair<const T1,T2>? 


	There is a tendancy I have notice amoung C++ programmers
to prefer member functions to globals. I'm going to put in an argument
for globals as the right way of doing 75% of what people usually
want members to do.

	My picture of a class is that it provides member functions
(and friends) which have a NEED to access the private implementation
details. These are called "Axioms". 

	The axioms can be said to "span" a space of potential
functionality/behaviour -- they're kind of basis vectors.
The space spanned is tha PUBLIC'ally accessible functionality
of the type: it is the set of all GLOBAL functions which can be
defined on the class.

	It is not necessary or desirable to limit the set of
member functions (and friends) to be the smallest possible set of
functions.

	Several factors ought to influence a decision to include
some functionality as a member, even when doing so does not
extend the space of functionality spanned.
 
IN FAVOUR OF BEING A MEMBER:

	1) USAGE: 
		Will the function be commonly used? 

	2) OPTIMISATION:
		 Will the function perform better if it has private access?

	3) INTERFACE COHERENCE: 
		Does the function form part of a coherent set of functions?

	4) BUILDING BLOCK:
		Does the function provide a significant combination
		of funtionality which is sufficiently
		different from other functions?

	5) Notational convenience of x.f() form

AGAINST BEING A MEMBER:

	1) MAINTAINABILITY:
		Functions with private access are harder to get right,
		and errors are less likely to attract a diagnostic:
		if a representation is changed, all member functions
		need to be examined for the impact, non-member non-friends
		will continue to work.

	2) CLUTTER:
		Lots of members clutter an interface


	3) LOSS OF POLYMORPHISM:
		Globals can work with SUBTYPES of their design type,
		and so they can apply to 

		a) other derived classes (ordinary functions)
 
		b) other types with the right looking interface
			(template functions)

	4) BREACH OF CLOSEDNESS
		Continually adding member fuctions defeats the
		purpose of encapsulation: to reduce dependence
		on implementation details to a fixed set of functions

NON-ARGUMENTS:

	1) namespace pollution. (Rubbish: we have namespaces)
	2) encapsulation (rubbish: the very idea of encapsulation
		implies a FIXED closed interface)

Here's a way to make a decision: consider a particular
representation and choose a minimal set of members to 
span the desired functionality space. Call these "axioms".

Now add in some important functions as members, call these
"theorems" -- these COULD be defined using only public
access.

Now consider another function f(): should it be a member or global?

The question to ask is: IF I CHANGED THE REPRESENTATION WOULD
A GLOBAL FUNCTION f() REMAIN EFFICIENT?

When you change the representation, of the set of existing members
"axioms" plus "theorms", some of the theorems might become
axioms and some of the axioms might become theorems -- the representation
might suggest which ought to be which for efficiency.

If some function is NEVER going to be changed when the representation
is going to change, it is a good candidate for a global.


OK: Now consider:

     
	m.insert(make_pair(3,5.0));
	m.insert(3, 5.0);

Providing BOTH these interfaces as members would be overkill.

	insert_pair(m, 3, 5.0);

is easy to implement -- and will work with ANY 
container taking a pair<> argument, saving adding this
function to every container.

	template<class Container, class Key, class Value>
	void insert_pair(Container &m, Key k, Value v) {
		m.insert(make_pair(k,v));
	}

is a possible implementation.

Note this particular implementation will work with a VECTOR as well:

	typedef VIF vector<pair<int, float> >;
	VIF x;
	insert_pair(x, 10, 4.5);

In fact, it is "portable". Because it belongs to the USER not
the container supplier.

IMHO: STL contains a reasonable set of requirements for containers:
it's a very good example of how to draw the line about 50% past
the minimal set of functions required to span the functionality
space of a container.

["50%" is merely an intuitive feeling, I haven't actually measured
the ratio theorems/axioms. A typical string class will have a higher
than usual theorem/axiom ratio because strings are heavily used
and subject to considerable optimisation depending on the implementation]

Comments?

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
	Maxtal Pty Ltd,		    
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21 
        NSW 2037, AUSTRALIA	    Phone: 61-2-566-2189

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]