There is a heated debate on the degree of uniformity one should expect of such systems: is a type an object? is a method an object? or should these three notions be treated differently? We can view this problem at three different levels: the implementation level, the programming language level and the interface level.
At the implementation level, one must decide whether type information should be stored as objects, or whether an ad hoc system must be implemented. This is the same issue relational database systems designers have to face when they must decide whether to store the schema as a table or in some ad hoc fashion. The decision should be made based on performance and ease of implementation grounds. Whatever, decision is made is, however, independent from the one taken at the next level up.
At the programming language level, the question is the following: are types first class entities in the semantics of the language. Most of the debate is concentrated on this question. There are probably different styles of uniformity (syntactical or semantical). Full uniformity at this level is also inconsistent with static type checking.
Finally, at the interface level, another independent decision must be made. One might want to present the user with a uniform view of types, objects, and methods, even if in the semantics of the programming language, these are notions of a different nature. Conversely, one could present them as different entities, even though the programming language views them as the same thing. That decision must be made based on human factor criteria.