quote:Original post by SabreMan
quote:
''Class'' only subsumes ''struct'' and ''enum'' if you use a definition of ''class'' that is not the definition used by C#. In which case, you''ll need to specify more clearly what definitions you''re using.
That''s what is meant by `letting actual implementations pollute the concepts''.
Eh? The word ''class'' is associated with a particular concept in C#. In C#, it is not associated with the concept you appear to be referring to, because C# ''class''
does not contain the behaviour of my hypothetical C# ''typedef''.
Again, I''m talking about introducing typedef into a specific language. It is meaningless to say "but ''typedef'' isn''t needed because, at a conceptual level, ''class'' does everything it can do and more" when
that isn''t the case for the specific language under discussion.
And, again, this is based upon
your conception of what a ''class'' is, which is clearly not the designers of C#''s conception of what a ''class'' is.
quote:
quote:
Since I was quite clearly talking about what I would have typedef do if I had the opportunity to add it to C#, I was obviously not discussing typesystems at the conceptual level.
Right, but before you can validate the need for typedef, you need to consider whether there is already a feature which fulfils the need. Therefore, you need to abstract the features under discussion.
That''s meaningless. There is no ''abstraction'' of the C# typesystem. ''Class'' means a specific thing, just as ''struct'', ''enum'', ''interface'' and ''delegate'' mean a specific thing.
Any abstraction you choose is necessarily one of your own devising. It is trivial to choose an abstraction in which every type is a ''class'' by defining ''class'' to denote what everyone else calls a ''type''.
However, you
cannot return from that abstraction to an actual implementation in a specific language without breaking the symmetry at some point.
You must choose whether objects will be stored directly or indirectly. You must choose whether objects will be callable. You must choose whether the object is limited to a finite prespeficied range of values.
C# doesn''t allow these features to coexist without extra work for the programmer. You don''t get ''delegate enumerations'', for example.
By necessity, a language divides the conceptual models of typing, control flow and modularisation into somewhat arbitrary distinct partitions.
An example is the partition between structs and classes. Structs cannot do inheritance, and classes cannot inherit from structs. If you want a type that can be a System.Int32, but can be transparently replaced with Yoyodyne.BigInt, you''re SOL with the C# typesystem -- there''s no way to define a subtype of a struct. The best you could do is use the preprocessor to replace Integral with one or the other. That''s a bad solution because the preprocessor doesn''t know about scoping and will replace Integral wherever it occurs. It''s also bad because it hides the ''type'' from a debugger.
typedef, on the other hand, can safely be used to define a subtype of a struct, it lacks the danger of conventional struct subtyping: a ''substruct'' which defines additional members is assigned to a variable of superstruct type: the struct''s additional members are lost, causing either damage to other objects stored after the struct in memory, or possibly a protection fault, if a virtual method tries to access them.
quote:
quote:
Interestingly, it doesn''t. The part of the Win32 API that deals with those handles exposes itself via a C interface. C doesn''t have classes. It actually uses structs.
Sigh...
Your point?
Perhaps you are saying that structs
are classes, and therefore it''s okay to talk about a C language API using classes, even though no concept with that name exists in the C language? If that''s what you''re saying then, again, proving whether or not a feature is needed at an arbitrarily constructed conceptual level doesn''t prove anything about what features should be present in an
actual programming language.
