F # configuration active en tant que membre non-statique

Question

Je ne suis pas sûr que membres du public non-statique des modèles actifs sont autorisés, mais vous pouvez les définir sans le compilateur se plaindre. Si elles sont autorisées quelle est la syntaxe pour faire correspondre contre un? Le compilateur me donne un décalage de type pour Foo dans FooBar2.doSomething. Attendre un 'a -> Choice<'b,'c> donné de 'a -> 'd -> Choice<unit,unit>

// No error in this class, static works great
type FooBar() = 
    static member (|Foo|Bar|) (x, y) =
        match x = y with
        | true -> Foo
        | false -> Bar

    member x.doSomething y =
        match x, y with
        | Foo -> ()
        | Bar -> ()

type FooBar2() = 
    member x.(|Foo|Bar|) y =
        match x = y with
        | true -> Foo
        | false -> Bar

    // compiler error on "Foo"    
    member x.doSomething y =
        match y with
        | Foo -> ()
        | Bar -> ()

Answer 1

modèles actifs ne doivent pas être utilisés en tant que membres. Le fait que ces compilent tout est un bug du compilateur que nous allons corriger (merci pour le rapport :)). L'utilisation locale ou lié module « let » s afin de définir une configuration active.

Answer 2

Je ne suis pas surpris que cela ne fonctionne pas, et je ne vois pas une interprétation sémantique naturelle par exemple des modèles actifs. Comment savez-vous quelle instance à utiliser lorsque vous voyez le modèle de Foo? Pourriez-vous avoir des instances différentes pour les cas de Foo et Bar (et donc une correspondance de motif incomplet)? Il ne semble pas être une résolution élégante aux questions ici. Pour être honnête, je suis surpris que même le cas statique fonctionne, et je ne vois rien dans la spécification d'adressage de la définition des modèles actifs en tant que membres de toute nature.

Answer 3

membres semblent reconnaisseurs être hors depuis la version 1.9.9.9. même pour les membres statiques. Je pense qu'il est dommage car il a permis la surcharge de reconnaissance. Je pourrais avoir un « nom » pour le type de reconnaissance, MemberInfo etc. Maintenant je dois avoir un « TYPE_NAME ». « MEMBER_NAME », etc. pour éviter les conflits de noms. Just 'Name' était plus agréable.