Ovidiu Deac

My feedback

  1. 15 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →

    This proposal is “approved in principle” for F# 4.0+. It would make a good addition to F#. (I don’t think the loss of purity (e.g. wr.t. ordering of union cases) is a critical problem and I believe you can turn of the DefaultAugmentation in any case)

    Some technical issues may need to be ironed out during implementation.

    If this is done, the Tag properties present on these types should also be revealed, that is covered by a separate item.

    An implementation and testing would need to be provided by someone in the F# community (possibly including Microsoft or Microsoft Research, though not limited to them).

    Implementations of approved language design can now be submitted as pull requests to the appropriate branch of http://github.com/Microsoft/visualfsharp. See http://fsharp.github.io/2014/06/18/fsharp-contributions.html for information on contributing to the F# language and core library..

    I’d be glad to help guide people through the implementation process.

    If you…

    Ovidiu Deac commented  · 
  2. 270 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    17 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
  3. 219 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Ovidiu Deac supported this idea  · 
  4. 457 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  37 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Ovidiu Deac commented  · 

    My thoughts:

    1. The property functions should be namespaced properly to avoid name collisions. For this reason I'm against the approach .PropertyName suggested below

    2. For starters doing it for record getters should be easy enough because one cannot define a record like this:

    type Point =
    {
    x : int
    y : int
    }

    static member x p = p.x

    // Error FS0023: The member 'x' can not be defined because the name 'x' clashes with the field 'x' in this type or module (FS0023)

    ...so if the above static member Point.x is automatically generated it shouldn't break existing code

    As Bryan Edds suggested below, this should also encourage people to use records more instead of classes.

    3. I wouldn't bother with the setters for now. The field updates could be considered as a separate feature and it probably needs more consideration.

    4. From the syntax perspective I think Point.x looks the most fsharp-ish.

    5. If you want to extend that to classes and other functions I like Python approach that member functions are just static functions which take the self instance as the first parameter. This way I the method calls below are identical in Python:

    c = MyClass()
    c.memberFunction()
    MyClass.memberFunction(c)

    For me that's simple and intuitive.

    I also like Robert Gibson's suggestion to put the instance parameter last for currying reasons.

    Ovidiu Deac supported this idea  · 
  5. 492 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    16 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Ovidiu Deac supported this idea  · 

Feedback and Knowledge Base