Is it reasonable to have more than 65536 User Defined Types in large projects?

Question

I'm thinking about some stuff related to runtime type info, and I'd like some feedback from programmers who work on much larger projects than I do. Is it at all reasonable to expect any program to ever have more than 65536 (2^16) user-defined types (classes and structs) in a single project? This does not mean 65536 instances, it means 65536 types. Would it matter at all in practice if a compiler limited you to 65536 classes/structs in any one project?

Answer 1

Who says type info == 16-bit number?

Answer 2

No, because at that point you should be strongly decoupling projects. Only the 'public-facing' types need to interact with each other across projects. Then the limitation becomes: maximum of 2^16 types per project, and maximum of 2^16 public-facing types across all projects.

Answer 3

I would consider this to be a constraint of the environment. In some systems types are generated automatically. In these occasions a big number of types would be created. Even if these aren't anywhere near 65536, why would you want to impose such a restriction?

In all modern applications/systems the count of all objects is only restricted by the system memory. It is a step backwards to have any other restriction.

Answer 4

It is a matter of priorities. Is the time (and amount of code) spent on implementing "unlimited" number of types justifiable in the current scope of the project?

You would also want to consider maintainability as the project/compiler grows.

I would say that special cases like having an obese amount of types don't really justify taking that into account if you're not specifically targeting this. Who is your target audience?

UPDATE: In some cases you might actually want to restrict yourself in order to become more efficient in some other aspect (like memory, execution speed, etc.) As long as it is clearly documented I think you should go with what fits your specific needs.