🚀 go-pugleaf

In article <mkohtala.726108774@vipunen.hut.fi> Marko.Kohtala@hut.fi suggests
the use of Class::{ /* ... */ } as syntactic sugar so that class members
could be defined in the scope without the need to explicitly put the class
prefix on each member.  He argues that this would make the code easier to
write and maintain.

His example is that
>
>Class::{
>  int var;
>  int func1() { /* ... */ }
>}
>
>... would be treated as
>
>int Class::var;
>int Class::func1() { /* ... */ }

I don't know if I agree with that reason, but I would like to see something
like this as a clean way to allow ``helper functions'' in the implementation
of the class.  This particular syntax has the advantage of being intuitive,
since ``Class::'' already means ``open the class scope in this context'' in
other places.

The semantics would be that all names defined in the scope would be visible
within the scope (subject to the usual scoping/visibility rules, of course);
names that were declared in the class description would be the only ones
exported from the scope.  This would allow a helper function to be defined
that had full access to the class private members, but still be type-safe,
since the only way to access the helper functions would be from within the
scope and the only way to enter the scope would be via the class interface.

That is,
	class Class {
	public:  int func1();
	};
	Class:: {
		int helper() { /* ... */ }
		int func1() { /* code including calls to helper() */ }
	}
Since helper() is not declared in the class, it is not exported from the
scope, while func1() is declared in the class, so it is exported in the
normal fashion.

I like it.  It's a way of sneaking up on modules/packages without adding
any new tokens to the language.

It does have the disadvantage that it makes the language larger.  On the
other hand, it would seem to eliminate the desire, expressed by several
people, for nested functions.  Such nested functions would usually be
helper functions in the implementation of a class, so by being able to
expand the class context to include non-nested functions would provide
an efficient solution.

So what do other people think?  It may be (probably is?) too late to
include this in the current C++ standardization effort, but if there is
some consensus that this syntax is reasonable, it might be possible to
nudge some vendors to try it as an extension.  (If it isn't too late,
how would I go about proposing it to the standards committee?)

If you grant that helper functions are needed, but don't like this idea
because it adds to the size of the language, an alternative would be to
take something that is syntactically legal but semantically forbidden and
define semantics for it.  I have thought about
	static /* type */ Class::Helper( /* params */) { /* ... */ }
which currently has no semantics (class functions cannot be defined as
static) and treat it as if it were declared (at file scope) as a private
member of the class.  It would only be accessible to members and friends
within the same file, so it too should be type-safe.
-- 
-- Greg Noel, Unix Guru         greg@qualcomm.com  or  greg@noel.cts.com

greg@qualcom.qualcomm.com (Greg Noel) writes:

>In article <mkohtala.726108774@vipunen.hut.fi> Marko.Kohtala@hut.fi suggests
>the use of Class::{ /* ... */ } as syntactic sugar so that class members
>could be defined in the scope without the need to explicitly put the class
>prefix on each member.  He argues that this would make the code easier to
>write and maintain.
[...]
>It does have the disadvantage that it makes the language larger.  On the
>other hand, it would seem to eliminate the desire, expressed by several
>people, for nested functions.  Such nested functions would usually be
>helper functions in the implementation of a class, so by being able to
>expand the class context to include non-nested functions would provide
>an efficient solution.

Many people seem to think that the purpose of nested functions is purely
as encapsulation, a sort of code organization/modularization feature.
While it is true that they do support this form of encapsulation, the
real reason that they are useful is their access to parameters and local
variables, and the fact that their addresses can be passed to any function
that just expects a function parameter.

If a local function never has its address taken, then it does not use
the full power of nested functions.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

In article <1993Jan8.044714.2027@qualcomm.com> greg@qualcom.qualcomm.com (Greg Noel) writes:
[...]
>The semantics would be that all names defined in the scope would be visible
>within the scope (subject to the usual scoping/visibility rules, of course);
>names that were declared in the class description would be the only ones
>exported from the scope.  This would allow a helper function to be defined
>that had full access to the class private members, but still be type-safe,
>since the only way to access the helper functions would be from within the
>scope and the only way to enter the scope would be via the class interface.
>
>That is,
>	class Class {
>	public:  int func1();
>	};
>	Class:: {
>		int helper() { /* ... */ }
>		int func1() { /* code including calls to helper() */ }
>	}
>Since helper() is not declared in the class, it is not exported from the
>scope, while func1() is declared in the class, so it is exported in the
>normal fashion.
>

You can accomplish the same thing with
	class Class {
	private: static int helper ();
	public:  int func1();
	};
although you don't get the syntactic sugar.

In article <1993Jan8.044714.2027@qualcomm.com> greg@qualcom.qualcomm.com (Greg Noel) writes:
>
>That is,
>	class Class {
>	public:  int func1();
>	};
>	Class:: {
>		int helper() { /* ... */ }
>		int func1() { /* code including calls to helper() */ }
>	}
>Since helper() is not declared in the class, it is not exported from the
>scope, while func1() is declared in the class, so it is exported in the
>normal fashion.
>

I agree fully with your desire to provide helper functions with access to
a class which do not appear in the class declaration and thus do not
cause recompilation when they are introduced or removed.  This is how I
do it, sticking to existing C++.  It's not as good as having language 
facilities to add helper functions into a class without affecting the 
header file, but for the moment it is adequate.  The drawbacks are 
introduction of another class name (which is publically visible), the 
need for qualification of the helper functions, and being careful about 
derived classes of Class when used in Class_helper.

Class.h:

class Class {
	friend class Class_helper;
	private: void func_private();
	public: int func1();
};


Class.C:

#include "Class.h"

class Class_helper {
	friend class Class;
private:
	static int helper() { ... }
	static int helper2(Class* c) { c->func_private(); ... }
};

typedef Class_helper Ch; // abbreviation 
static Class_helper CH; // just for convenience -- see usage examples below

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

int Class::func1() {
	Class_helper::helper(); // take your pick of these three alternatives
	Ch::helper();
	CH.helper();

	Ch::helper2(this);
}


It would be nice to be able to make Class_helper a nested class within Class
while still declaring it in Class.C; but if that were made possible, I imagine 
that the problem which gave rise to this programming idiom could be fixed
directly.

One can also derive Class_helper from Class to get at Class's member functions
directly.  Then helper2 does not need to be static and does not need an
argument, but there would need to be a conversion from Class* to Class_helper, 
so there is not a lot of gain.

David R. Cok
Eastman Kodak Company
cok@Kodak.COM