On 11/28/05, Wolfgang Jeltsch <[EMAIL PROTECTED]> 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
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
