On 11/28/05, Wolfgang Jeltsch <wolfgang@jeltsch.net> wrote:
As I already said, this approach may lead to mixing different concepts. Example:
data Person = Person { name :: String } data File = File { name :: String }
A field identifier has to be seen in context of the datatype it belongs to. When used in conjunction with Person, name means a person's name while it means a filename (a notably different thing) when used in conjunction with File. With the typeclass approach, we would have a single function called "name" which deals with different things. Important details would just be camouflaged. This is not good. In fact, it is really bad in my opinion.
Hi Wolfgang, I think you are right in that two similarly named fields should not be automatically considered to be equivilent. Indeed that is why the typeclass approach I proposed requires that one explicitly declare any typeclasses, and explicitly declare when two similarly named fields are part of the same typeclass -- one thus cannot have two fields been considered equivalent without the programmer making a conscious descision that this is correct behaviour.
Maybe it would really be better to have functions like Person.name and File.name?
In the case you give, I think you are right. In this case, using namespaces to distinguish fields is preferable to treating the same. However I think there are also other cases in which it *is* desirable to allow several datatypes to have the same field -- with the programmer making a contious descision to do things this way. [snip] -Rob