Search Unity

JobHandle.IsCompleted does not match naming scheme of remaining API's

Discussion in 'Entity Component System' started by Peter77, Feb 2, 2018.

  1. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,618
    Unity uses camel-case (initial lower case letter) for properties across its entire API's, yet JobHandle.IsCompleted uses pascal-case (initial upper case letter).

    Is this considered an issue? Is this a known issue?
     
    Peter77, Feb 2, 2018
    #1

  2. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    For completely new API's we are using the .NET standard conventions.
     
    Joachim_Ante, Feb 2, 2018
    #2
    Qbit86, starikcetin, lilymontoute and 3 others like this.

  3. recursive

    recursive

    Joined:
    Jul 12, 2012
    Posts:
    669
    Neat. After looking at them I was wondering if that WasTheCase.
     
    recursive, Feb 6, 2018
    #3

  4. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    6,363
    when you make such decisions you need to consider new users that will see a mix of both, less readable autocomplete list and that unity is a black box so do i care if it's a property or a variable? no not really
     
    laurentlavigne, Feb 6, 2018
    #4

  5. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,456
    Yes Unity is a black box but knowing whether you are accessing a property or a variable has value when you're looking to optimize your code. E.g. Time.deltaTime, which feels like it could be a variable set per frame so what's the cost in querying right? Except caching it for critical path and in loops has a tangible performance benefit because it is a property with a call overhead.

    Yes mixing things is unfortunate but so is the old approach of not differentiating, so...
    Also, I do realize that the mixing is making this worse for new Users for whom e.g. Time.deltaTime now looks especially like it is not a property. Your concerns are valid and thanks for bringing them up. I just felt like addressing your stance of not caring to know. I too didn't care once and I think in part because it wasn't obvious.
     
    MartinTilo, Feb 6, 2018
    #5
    laurentlavigne and recursive like this.

  6. recursive

    recursive

    Joined:
    Jul 12, 2012
    Posts:
    669
    From just looking at the new APIs, they're all in a Unity namespace instead of the UnityEngine namespace. Feels like this is meant to help people identify what context to approach code when it comes to stuff like this and advertise that new subsystems will have a "clean break" from the old style of code.

    Would it be impossible to see conversions of old APIs over time? Will new editor subsystems start going into Unity.Editor instead of UnityEditor?

    I'm mostly just curious, I started using the .NET style (mostly) and haven't really looked back.
     
    recursive, Feb 6, 2018
    #6

  7. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,456
    Sorry, I don't feel like I'm qualified to give you a definitive or even remotely authoritative prediction on this so I'm going with a definitive probably not maybe... ;)
     
    MartinTilo, Feb 6, 2018
    #7

  8. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    Its not a decision we took lightly. There is a big negative impact to change almost every existing API entry point in unity on the ecosystem even with script upgrader support in terms of breaking libraries / code etc.

    The approach of new code in Unity namespace following better conventions is what we decided on in the end. And yes we took that decision fully knowing that it leads to a temporary (A couple years) inconsistency in our API's. It's better to starting moving code into a new consistent future and not break anything in the process - is the very sumarized conclusion.
     
    Joachim_Ante, Feb 9, 2018
    #8
    Qbit86, OswaldHurlem, Corvwyn and 5 others like this.

  9. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,981
    This makes it sound like eventually the plan is to remove the old API entirely and just have the new, well written API in a couple of years?

    Not saying that's a bad thing, just curious!
     
    MadeFromPolygons, Feb 9, 2018
    #9
    Krajca likes this.