🚀 go-pugleaf

In article <1992Oct6.011951.10984@cadsun.corp.mot.com> shang@corp.mot.com writes:
>In article <23808@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:
>> In article <0enxJ1W00awTMNepU8@andrew.cmu.edu>, osoelgaultier+@CMU.EDU  
>(Stefan Monnier) writes:
>> 
>> > As are currently implemented templates, you don't know
>> > anything about the actual type at compile-time.
>> > So that no method calls or variable accesses can be compiled
>> > for any variable of 'template type'.
>> 
>> But you still haven't answered my question.
>> 
>> My question was: what reason do you have to believe that
>> adding inheritance constraints would solve the problem?
>> 
>> In thinking about the answer, don't forget about inline functions.
>> -- 
>> 				--Andrew Koenig
>> 				  ark@europa.att.com
>
>Please note that a constrained parameterized class is a completely 
>different language concept from C++ template, though it can replace the  
>template concept anyway.
>
>A constrained parameterized class is an abstract class. You need not to
>"instantiate" it before using it. Compilers can generate real executable 
>codes for member functions defned in a constrained parameteried class. 
>Once a parameterized class is compiled separately, the compiler can 
>ensure no type-error related to the usage of the class parameters. 
>Therefore, there is no need to expose the source code to the user. What 
>the user need to prove is that whether his/her actual parameter is 
>conformable to the class parameter specification. For library-developers, 
>since the code is already generated by the compiler and built into a 
>library, it is no longer needed for them to ship the source code with 
>their products.
>

	We already have abstract classes that are precisely what
you want. A generic class even with constraints CANNOT generate
actual code until instantiated. But it CAN be type checked
at compile time.

	Restricting a generic parater to a Base class is pointless.
It only allows you to generate actual code in precisely those
cases where you didn't need a template in the first place.

	I think there are two types of templates:

	1) completely unconstrained. Actually, there is no
	such thing, there ARE constraints, but they are implicit
	in the source of the defintion.

	2) completely constrained. In this case you have to
	list all the properties of the parameters and even
	some relations between them.

	This implies you can completely type check the template
	definition. And thus, you can give meaningful error messages
	(constraint xxx violated) when you do a bad instantiation.

	But you still cant fully compile code.

	Or can you? Suppose the constraints were global functions.
	The the generic procedure would take some hidden
	parameters, these being the address of these functions.

	Mm. For data members, it would have to be say the offset,
	and for member functio the address (or, for virtuals,
	something more ...)

	The problem might be that something so comletely constrained
	would be less useful than unconstrained genericity.
	For example, it would not be enough to say T has a data member
	'number' which was numeric to add it to something. You would
	have to say it was 'int'.

	If the really tight constraints I propose are provided,
	you could perhaps compile a generic function.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------