🚀 go-pugleaf

In article <1358@appli.se> niklas@appli.se (Niklas Hallqvist) writes:
>rfg@NCD.COM (Ron Guilmette) writes:
>
>:In article <1991Apr19.183922.1982@kodak.kodak.com> cok@islsun.Kodak.COM (David Cok) writes:
>
>I've thought about this, and come to the same conclusions as Ron.
>Well, how should the "use" syntax look like?  How about:
>
>default class CLASSNAME-LIST {
>  // code goes here;
>}
>
>This way, we won't need to introduce new keywords.  Possibly the
>"class" keyword could be left out but I think it makes the code
>more readable...

>... Should we (the net) try to write a proposal
>to the ANSI commitee before their june meeting in Lund, Sweden (at
>least I think that's the case, some of the members will speak at
>some seminars there, which I'll try to attend).

Sure.  Why not?  I think that the x3j16 committee (and especially the
libraries working group) would  probably thank us for it.

Let me see if I can get the ball rolling a bit (and see where it goes).

First off, I must say that I think that the proposal should be entirely
non-committal about the specific syntax and keywords used.  We know what
our *real* goal is right?  We want a specific *feature*.  None of us
is going to die if the keywords which must be used to code an instance
of that feature are something other than what we would prefer.  I think
that most of us can manage to adapt to whatever keywords x3j16 likes
best, as long as we get the *feature*.  Arguing for a specific keyword
(or set of keywords) is only likely to turn-off some members of x3j16,
so why not just propose the feature and ask x3j16 to decide what keywords
they want to use to express it?

Here are some of the possibilities:

		module <identifier> { ... };
		package <identifier> { ... };
		default class <identifier> { ... };
		class <identifier> static { ... };

Let's not argue about that.  Let's just pick some convenient "stand-in"
for the syntax/keywords (just for now) and let argue instead about the
important rules that should apply to this general "feature".

For the sake of example (only) I'll use a (hypothetical) new keyword, i.e.
"package" and I'll assume that the real choice will be left to x3j16.

Now.  What are the rules applicable to this feature?

Well, I can think of a few right away:

	The name of a "package" is (in general) treated like a class name,
	except that you are not allowed to declared objects of a "package"...
	i.e. the following is illegal:

		package foobar { ... } object;

	as is:

		package foobar { ... };
		foobar object;

	You are not allowed to take the address of a "package".  (That's
	only logical, since the only name that you have for it acts
	mostly like a class name anyway, and it's likewise nonsensical
	to take the address of a class name.)  Also, there are no pointers
	to packages, references to packages, or pointers to members of
	packages.

	All data and function members of a "package" are implicitly "static".
	They may also be *explicitly* declared to be "static", but in such
	cases, there must be a definition of the given member somewhere
	(later) within the same compilation unit, and these definitions
	will be given "static linkage" by the compiler.

	Function members of packages may never be declared to be virtual.

	Since there are no references to packages (and since they would
	nonsensical anyway) packages DO NOT automatically have copy
	constructors or assignment operators implicitly generated for
	them (by the compiler).  (Each package does however get a default
	constructor generated automatically for it by the compiler if one
	is not explicitly provided.)

	A package may have a constructor and a destructor.  If provided, the
	constructor and destructor act just like static member functions
	(i.e. they have no `this' pointer).  If provided, a package
	constructor must take no arguments, and this constructor will be
	automatically invoked once (before main() is entered).  It is
	never invoked otherwise (not even during the construction of an
	object of some class type whose type inherits from the package).
	If provided, a package destructor is invoked once (after main()
	is exited).  It is never invoked otherwise (not even during the
	destruction of an object of some class type whose type inherits
	from the package).

	In all other respects, "packages" act like classes.  In particular,
	package declarations may be nested within functions, within class
	declarations, or within other package declarations.  Likewise,
	classes, packages, and function declarations and definitions
	may be nested within packages.  Furthermore, packages are treated
	just like classes when it comes to inheritance.  You can inherit
	from a package and a package can itself inherit (from either a class
	or from another package).  The "public", "private" and "protected"
	specifiers have all of the same meanings for packages as they do
	for classes.

	Since data and function members of packages are always static,
	taking the address of a member of a package yields a pointer
	to an object or a pointer to a function (respectively) just as
	would be the case for static members of class types.

Did I miss anything?

Oh yes... separately (by attached to this same proposal) there must ultimately
be a description of the proposed "use" statement (if people agree that such
a thing would be needed in case we got "packages").

I don't have time to write that up today, though.

-- 

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