struct

Mark S. Miller erights at google.com
Tue Jun 9 13:02:52 PDT 2009


On Tue, Jun 9, 2009 at 11:05 AM, Sam Ruby <rubys at intertwingly.net> wrote:

http://en.csharp-online.net/ECMA-334:_18._Structs
>

Hi Sam, thanks for the pointer. I will read.

Taking Rational as an example, the following makes sense to me.  Anybody
> differ?
>
>  Rational(2,1) ==  2             ==> true
>  Rational(1,2) ==  Rational(2,4) ==> true
>  Rational(2,1) === 2             ==> false
>  Rational(1,2) === Rational(2,4) ==> false


Rational's may be a bad example, because if I were implementing them, they'd
always reduce to canonical form on construction so my last result above
would be "true". However, in the spirit of your question, we can suppose a
Rational representation which doesn't auto-canonicalize. In that case I
agree with these outcomes.



> Given the above, the answer to the below is less clear:
>
>  foo = {}
>  foo[Rational(4,2)]='a'
>  foo[Rational(2,1)]='b'
>  foo[2]='c'
>
>  foo[Rational(2,1)] ==> 'b' ???
>  foo[Rational(4,2)] ==> 'a' ???
>

Since Rational, being a struct, can overload operators (other than ===, !==,
&&, ||, and ?:), then your second case should be equivalent to

  Rational(4,2)['reverse[]'](foo, 'a')


> The motivation for the above is the question of whether or not there
> will be the possibility of any user visible cohorts.
>

User visible cohorts do not violate any principle associated with structs
and operator overloading. Indeed, it is impossible for such an extensible
framework to prevent library authors from introducing such types themselves.
Whether we want to standardize a numeric type with this behavior is another
matter. I don't. That's one of the reasons I'd build Rationals that
auto-canonicalize.

-- 
   Cheers,
   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090609/06057f82/attachment.html>


More information about the es-discuss mailing list