🚀 go-pugleaf

In article <1991Apr21.014746.3526@kestrel.edu> gyro@kestrel.edu (Scott Layson Burson) writes:
>In article <5143@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>>The problem is *not* one of establishing new "modules" or new "namespaces"
>>(which class declarations can do quite well, thank you).
>
>Except that as you point out later on in your message, there is
>currently no way to wrap a class declaration around a group of
>top-level declarations and have them be treated as static members by
>default...
>>							   No.  The problem
>>is that if you do this, it becomes quite cumbersome to *reference* the
>>things whose declarations you have now nested within class declarations.
>>Specifically, it is quite irritating to have to write out the extra
>>CLASSNAME:: qualification all over the place.
>>
>>How can this problem (i.e. the *real* problem) be solved?
>
>Though I'm not opposed to an attempt to solve this problem in some
>such way as you suggest, I think you overrate it.

OK.  Perhaps I do.  Let's agree that there are two problems here, namely:

	We need a feature (similar to classes) which will (by default)
	make any data member or function member `static' by default.
	(Note that all sorts of things like typdefs, enum types, struct
	types, union types, class types may now also be `members' of some
	containing class, but staticness/non-staticness is only an issue
	for the data members and function members.)

	We also need a related feature which would "open the scope" of
	such a "module" (within some other scope) so that (within that
	other scope) we don't have to deal with the tedium of writing
	CLASSNAME:: all of the time.

Regarding the latter problem, I wrote:

>>... it would probably be better to
>>have something more like an Ada `use' statement to solve this problem.
>
>I agree that this would be handy.

OK.  One down.  Now... about that first problem... given that we can nest
groups of declarations in `class' declarations...

>>... there would still be that irritating
>>need to declare data and function members as `static'.  That's where having
>>a `module <identifier> { ... }' construct would come in handy.  We could
>>define a `module' to be just like a class except that its data members and
>>function members would all be *implicitly* static.  Still, I'm sure that
>>we're all against introducing new keywords if it could be avoided, so how
>>about just using `class <identifier> static { ... }' rather than requiring
>>`module <identifier>'.

>Personally, I would prefer the introduction of a keyword in this case.

I would prefer it myself, but remember that each tiny change of that sort
causes the x3j16 membership to scream bloody murder.  If we could convince
x3j16 *just* that "default-static" classes and `use' statements were
essential, I would say that we would have done a damn good day's work.
It would be pushing our luck to imagine that we might also be successful
in slipping in a new keyword to boot!

>... Also, if there were also some sort of
>`use' declaration, I think I would really want it to work only on
>modules;...

I disagree.

>...otherwise its definition has to be that it makes the names of
>only static members visible, because it wouldn't make sense to make
>the names of normal (nonstatic) members visible...

I don't see anything wrong with  a generalized "opening of the scope"
which applies to both static and non-static members.  In some cases,
it might actually be useful.  For example:

	struct S {
		int data_member;
		void func_member (void);
	};

	int S::*data_mbr_ptr;
	int S::*func_mbr_ptr;

	int i;

	void example ()
	{
		use S;		// scope opener

		i = S::data_member;	// error - no object specified
		i = data_member;	// error - no object specified

		S::func_member();	// error - no object specified
		func_member ();		// error - no object specified

		data_mbr_ptr = &S::data_member;		// OK
		data_mbr_ptr = &data_member;		// also OK

		func_mbr_ptr = &S::func_member;		// OK
		func_mbr_ptr = func_member;		// also OK
	}

-- 

// Ron ("Loose Cannon") Guilmette
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// New motto:  If it ain't broke, try using a bigger hammer.