Unity Community


Page 3 of 13 FirstFirst 12345 ... LastLast
Results 41 to 60 of 253

  1. Location
    Gold Coast, Australia
    Posts
    3,593
    Quote Originally Posted by Jessy View Post
    I forgot that Queue came in a non-generic variant. I couldn't figure out any way to match your code after I realized that boxing was going on.
    Exactly. It's not just boxing [though that's important to note] - but the lack of strong typing.

    Quote Originally Posted by Jessy View Post
    Those names are horrible!
    Code:  
    1. public static void SetPosition (this Transform transform,
    2.     float? x = null, float? y = null, float? z = null)
    3. {
    4.     Vector3 position = transform.position;
    5.     if (x.HasValue) position.x = x.Value;
    6.     if (y.HasValue) position.y = y.Value;
    7.     if (z.HasValue) position.z = z.Value;
    8.     transform.position = position;
    9. }
    I wish there was some way to combine UnityScript's avoidance of the limitations of properties with this swizzle-esque ability though:
    Code:  
    1. transform.SetPosition(x:3, z:5);
    Nice

    This is why I like C# - inventive problem solving, rather than relying on the couple niceties already built in. Though I *might* have tried to use a magic value [e.g. nan] instead of boxing for performance reasons. Hmm... should benchmark that.

    Quote Originally Posted by Jessy View Post
    If UT could keep feature parity between UnityScript and C#, it would be a different story.
    What US needs, if it wants to continue to exist, is MORE FEATURES. "cause - baring an amazing rebuttle, it's not shorter than C#, or fast, or simpler in many many regards - both simple and complex code. It's almost as if the U3D team is holding C# back to give US some differentiation.

    I know I'm going to cop some flack for that - and bring it on. But take a look at how things could be done vs how they are - and there's a lot of improvements that could be made. Creating US snippets but not C# snippets isn't a smart decision if you think about it.

    Disclaimer: This isn't a deliberate choice on U3D's part [at least I hope not] - just an interesting turn of history.


  2. Location
    Ryazan, Russia
    Posts
    781
    Code:  
    1. public static class Extensions
    2. {
    3.     public static T Replicate<T>(this T sample) where T : Object
    4.     {
    5.         return (T) Object.Instantiate(sample);
    6.     }
    7. }
    The problem solved once and for all.

    Usage:
    Code:  
    1. var clone = prefab.Replicate(); // Short and type-safe

  3. Super Moderator
    Location
    Great Britain
    Posts
    9,683
    What about people who can code C++ fine but love unity js? That'd be me.

    I accept it is in fact limiting compared to C++ - there's some limits to it such as getters and setters not functioning correctly and presumably you can probably still use pointers (maybe it's faster for some magical thing someone wants to do).

    But I like the simplicity of just... coding. There's no thinking about anything, just throw it out there and iterate. UJS has that brainlessness I really enjoy.
    Currently working with Sony on our new
    PS4 and Vita game in Unity!

    This post is not representative of Simian Squared Ltd


  4. Location
    NE Ohio, USA
    Posts
    7,173
    Quote Originally Posted by alexzzzz View Post
    Code:  
    1. public static class Extensions
    2. {
    3.     public static T Replicate<T>(this T sample) where T : Object
    4.     {
    5.         return (T) Object.Instantiate(sample);
    6.     }
    7. }
    The problem solved once and for all.

    Usage:
    Code:  
    1. var clone = prefab.Replicate(); // Short and type-safe
    This should be unnecessary. The docs list a generic form of Instantiate, which should match this. But it doesn't work.

  5. Volunteer Moderator
    Posts
    23,730
    Quote Originally Posted by NPSF3000 View Post
    The only religious bollocks is the anti-religious bollocks coming from some members of the US camp :P
    Sorry, but you didn't actually address any of my issues with C#. Except Action--that was valid. None of the others were. Things like using an alias instead of importing the class--I know about that, and it doesn't really help. It just shortens things a bit, and confuses the issue, rather than actually doing what Unityscript does more easily (and your example was especially poor since GL is already a class in Unity). You either dismissed my issues as irrelevant (which I *knew* you were going to do--but I'm the one working on my code, not you--I get to decide if they're relevant, not you--saying "meh" just concedes the point), or you tried to sidestep them by creating other functions, which doesn't actually address the issues. I can write a bunch of functions in Unityscript too; that's really not the point. The point is the standard, built-in behavior. So yeah, not convincing at all, sorry. (The word, by the way, is "definitely", not "defiantly".)

    --Eric
    SpriteTile: new tile system that works seamlessly with Unity 4.3 sprites
    FlyingText3D: dynamic 3D text with TTF fonts | Vectrosity: fast & easy line drawing
    Nifty utilities! Stitch terrains together - runtime model importing - file browser - fractal landscapes


  6. Location
    Austin, TX
    Posts
    604
    Quote Originally Posted by NPSF3000 View Post
    The only religious bollocks is the anti-religious bollocks coming from some members of the US camp :P
    No, sorry - you're the extremist, whereas Eric is advocating tolerance.

    Me, I think they should get rid of C# and ban it's mention from the forums, and revoke the licenses of people that use it, and put them in a dungeon and gently flog them until they sincerely admit that they are wrong.


  7. Location
    Ryazan, Russia
    Posts
    781
    Quote Originally Posted by Jessy View Post
    This should be unnecessary. The docs list a generic form of Instantiate, which should match this. But it doesn't work.
    In reality there's no generic form:

    Name:  reflector.PNG
Views: 346
Size:  24.7 KB

    Anyway prefab.Replicate() is shorter than Instantiate<GameObject>(prefab), there's no need to specify the type.


  8. Location
    NE Ohio, USA
    Posts
    7,173
    Quote Originally Posted by alexzzzz View Post
    Anyway prefab.Replicate() is shorter than Instantiate<GameObject>(prefab), there's no need to specify the type.
    I'm not arguing against your syntax. I think it's the best option that C# offers, and should be in the API. However, I am arguing that another name is unnecessary. There's no reason to call it "Replicate" instead of "Instantiate".

    Quote Originally Posted by Eric5h5 View Post
    I can write a bunch of functions in Unityscript too
    Not with the brevity that you prize. Or maintainability. Your examples favor UnityScript, but they represent too small a subset of software construction. All of your syntactical arguments will be trifles unless UnityScript can match the functionality of C#. The languages are too similar for UnityScript to be a rational choice at present. Boo might be worth supporting, but nothing is helping any of us make that assessment, so I have no opinion on it. UnityScript comes off as a pointless endeavor to me.
    Last edited by Jessy; 04-13-2012 at 11:53 AM.


  9. Location
    Sooke
    Posts
    3,218
    Quote Originally Posted by polytropoi View Post
    Me, I think they should get rid of C# and ban it's mention from the forums, and revoke the licenses of people that use it, and put them in a dungeon and gently flog them until they sincerely admit that they are wrong.
    I have a sudden urge to punch you... huh.



    Anywho, I really don't think any language should be removed in Unity. Choice is good. All you people are doing is arguing like religious people do over which God is real.

    In the end, all the languages will get the job done.
    -Insert quote here
    ---Famous Person

  10. Volunteer Moderator
    Posts
    23,730
    Quote Originally Posted by Jessy View Post
    Your examples favor UnityScript, but they represent too small a subset of software construction. All of your syntactical arguments will be trifles unless UnityScript can match the functionality of C#. The languages are too similar for UnityScript to be a rational choice at present.
    Again, you don't get to decide what a "trifle" is for me. I already mentioned to start with that most of those things taken individually wouldn't be that big a deal, it's all of them together, constantly, that gets wearying.

    UnityScript comes off as a pointless endeavor to me.
    So don't use it; I wouldn't try to convince you that you should. But don't be one of those people who doesn't understand the concept of "difference of opinion". You're not "right" about C#, you just have an opinion. At the end of the day, it's about using whatever tool that helps you actually get something out the door.

    --Eric
    SpriteTile: new tile system that works seamlessly with Unity 4.3 sprites
    FlyingText3D: dynamic 3D text with TTF fonts | Vectrosity: fast & easy line drawing
    Nifty utilities! Stitch terrains together - runtime model importing - file browser - fractal landscapes


  11. Location
    NE Ohio, USA
    Posts
    7,173
    Quote Originally Posted by Eric5h5 View Post
    You're not "right" about C#, you just have an opinion.
    I'm not convinced of that, but I'm open to being convinced. My current understading is that C# supports all of the programming paradigms that UnityScript does, but not vice versa. Language features are factual data, though.

    Quote Originally Posted by Eric5h5 View Post
    At the end of the day, it's about using whatever tool that helps you actually get something out the door.
    Life occurs before the end of the day. If other people have opinions that lead to things I spend time with to be worse than they are, or could be, then I think it's justified to be displeased about it. Unity doesn't yet have a competitor, as far as my requirements go.

    Edit: I was thinking, there are some tools that I use, which I don't like having to use, but that are worth it, for the result. If that's what C# is to someone, then that's fair. (Like I said far above, I don't want to be using C#, but I think it's the best option available for Unity.) If, however, one makes the choice to use UnityScript, in its current incarnation, while knowing its limitations, then I see that as a mental condition to overcome. The differences are too minor to consider UnityScript at present.
    Last edited by Jessy; 04-13-2012 at 01:51 PM.


  12. Posts
    452
    I agree to abandoning 2 of the 3 available languages. I don't care which one to stick to, either C# or JS, but one of them is obsolete (and Boo obviously). If you start with JS you get annoyed later on since most 3rd party scripts are written in C#, so the other way around is more preferable. But actually I wouldn't mind if it were JS only (which in fact is UnityScript, not Javascript) and no C# support. Just stick to a single one. Call it Unityscript, the same way UDK has its only UnrealScript language. A single scripting language would also clean up the docs, the bloat, optimize the maintenance, prevent confusions. Time that can be invested in other things.

    My impression is, that Unity Tech tries to support everything and then everything is only maintained and working half-way. The same applies to TextEditors e.g. UniScite / Monodevelop. If UT focused on its original Editor all these issues could have been fixed - but now we have 2 buggy editors. Great.

    Not to talk about their attempts to make conquer more technologies e.g. Flash etc. and by that forgetting to implement long overdue features in the game engine such as e.g. Terrain shaders. It's about time to stop the bloat.


  13. Location
    Rapid City, SD, USA
    Posts
    1,569
    Quote Originally Posted by marctro View Post
    but one of them is obsolete (and Boo obviously).
    Car to elaborate and share your reasoning why boo is obsolete (which I happen to disagree on)?


  14. Location
    Ryazan, Russia
    Posts
    781
    1.
    Code:  
    1. // C#
    2. var c = '1';
    3.  
    4. // UnityScript
    5. var c = "1"[0]; // Who needs chars while we have strings?

    2.
    Code:  
    1. // C#
    2. List<string> list;
    3.  
    4. // UnityScript
    5. var list : List.<String>; // Verbose. What does the dot stand for?
    I can write either 'int' or 'Int32', either 'float' or 'Single', but must always write 'String' and never 'string'. Why?

    3.
    Code:  
    1. // UnityScript
    2. var rect = Rect(0, 0, 100, 10); // It looks like a function call, but is still legal without 'new' keyword.
    3. var array = int[50]; // Then why is this illegal? What's the difference?

    4.
    Code:  
    1. // C#
    2. struct Abc
    3.  
    4. // UnityScript
    5. class Abc extends ValueType // Are you joking?

    5.
    Code:  
    1. // C#
    2. int Abc()
    3.  
    4. // UnityScript
    5. function Abc()
    Useless 'function' keyword is necessary, but useful return type is optional. Very user-friendly

    6.
    Code:  
    1. // C#
    2. list.RemoveAll(x => x == null);
    3.  
    4. // UnityScript
    5. list.RemoveAll(function(x) x == null);
    It was a bit tricky to find the info about lambda syntax because UnityScript language reference doesn't exist. If I didn't know from somewhere that UnityScript supported lambdas, I would be sure it didn't.

    7. C# + Visual Studio
    Name:  cs.PNG
Views: 378
Size:  14.8 KB

    US + MonoDevelop
    Name:  js.PNG
Views: 387
Size:  18.9 KB

    I knew MonoDevelop's auto-completion was bad for C#, but in case of UnityScript it's beyond good and evil.

    8. Now my favorite example of MonoDevelop uselessness:

    Сorrect code:
    Code:  
    1. function Start ()
    2. {
    3.     var rnd = System.Random(100);
    4.     var array = new int[50];
    5.     for (var i = 0; i < array.Length; i++)
    6.     {
    7.         array[i] = rnd.Next(10);
    8.     }
    9.    
    10.     var temp = Enumerable.Select(array, function(x) x.ToString()); // Yeah, let's try some LINQ!
    11.     var result = String.Join(", ", Enumerable.ToArray(temp));
    12.     Debug.Log(result); // Prints 50 random numbers separated with commas
    13. }

    Code full of mistakes:

    C# + Visual Studio
    Name:  cs2.PNG
Views: 333
Size:  16.5 KB
    US + MonoDevelop
    Name:  js2.PNG
Views: 333
Size:  12.8 KB

    Rhetoric question: how much time it would take you to find and correct all the mistakes in both editors?

    The funny thing is that UnityScript is usually considered to be a bit easier for beginners than C#, but considering 6, 7 and 8 I can't imagine how this could be true. The beginner should have much passion and patience to deal with UnityScript, definitely more than I have.


  15. Location
    Gold Coast, Australia
    Posts
    3,593
    Quote Originally Posted by Eric5h5 View Post
    Sorry, but you didn't actually address any of my issues with C#. Except Action--that was valid. None of the others were. --Eric

    Err What? Did you read what I wrote?

    Useless import/class declaration fluff - unnecessary.

    • Long Winded GetCetComponent - Use the shorter version [which can be just as fast].
    • Instantiate has 'as T' fluff - use generics to remove fluff.
    • new GameObject requires typeof to add components - use generics.
    • Transform.position.x - add a set position methods that's even cleaner/shorter.
    • yield return StartCoroutine(Thing()); - WIP.


    If US is genuinely better/smaller/simpler fine. But when I've countered half your examples with equivalents or better - just ignoring them is pointless.

    If US can do things simpler than C# - then fine keep it. If by having US we are just splitting the community, implementing poor API choices that artificial increase C# complexity, and ignore all the times where C# is actually smaller and cleaner than US [alexzzzz has beaten me to start showing these examples] then it's something worth discussing.

    Quote Originally Posted by Eric5h5 View Post
    I get to decide if they're relevant, not you--saying "meh" just concedes the point)
    Exactly.... if I say *meh* it means there's nothing I could think of to counter it.

    Quote Originally Posted by Eric5h5 View Post
    or you tried to sidestep them by creating other functions, which doesn't actually address the issues. I can write a bunch of functions in Unityscript too; that's really not the point. The point is the standard, built-in behavior.
    1) You cannot create new functions anywhere near the extent we can, due to a lack of generics and extensions - we are just using our language to make our language more efficient.

    2) There is no such thing as standard behavior - read the title:

    Make JS and Boo deprecated in Unity 4. And non-functional in Unity 5

    What we are doing here is trying to see how U3D, with minimal effort, remove US and replace it with C# that, thanks to a few API tweaks and maybe snippets, is nearly identical in simplicity when it comes to 'scripting'. Several of your complaints against C# where poor API [or snippet] decisions on part of U3D that artificially made US seem simpler when that wasn't the case.

    My personally suggestion for US proponents is start adding features to your language - oddly enough one of the few things you can do with it.


  16. Location
    Rapid City, SD, USA
    Posts
    1,569
    Quote Originally Posted by NPSF3000 View Post
    Make JS and Boo deprecated in Unity 4. And non-functional in Unity 5
    As far as making these languages deprecated, JS I can kind of see, but I believe you are jumping the gun a little bit considering Boo is still somewhat new.


  17. Location
    Sooke
    Posts
    3,218
    Quote Originally Posted by OmniverseProductions View Post
    As far as making these languages deprecated, JS I can kind of see, but I believe you are jumping the gun a little bit considering Boo is still somewhat new.
    Boo has been there from the start.
    -Insert quote here
    ---Famous Person


  18. Location
    Rapid City, SD, USA
    Posts
    1,569
    Quote Originally Posted by killer1390 View Post
    Boo has been there from the start.
    I think boo appeared in 2003 right? In any case I'll expand on my boo comment. I was saying to wait until at least version 1.00 but preferably a few minor releases after.


  19. Location
    Gold Coast, Australia
    Posts
    3,593
    Quote Originally Posted by polytropoi View Post
    No, sorry - you're the extremist, whereas Eric is advocating tolerance.

    Me, I think they should get rid of C# and ban it's mention from the forums, and revoke the licenses of people that use it, and put them in a dungeon and gently flog them until they sincerely admit that they are wrong.
    :P

    I sincerely hype that people don't jump one the extremist or religionist bandwagon.

    • There are real known issues with haveing multiple languages.
    • There are real known issues with the implementation of US.
    • There are real known issued with the implementation of C#.

    These are things that can be improved upon - to simply write it off as a rant means that you're happy to be stagnant - which ain't good for survival.


  20. Location
    Gold Coast, Australia
    Posts
    3,593
    Quote Originally Posted by OmniverseProductions View Post
    As far as making these languages deprecated, JS I can kind of see, but I believe you are jumping the gun a little bit considering Boo is still somewhat new.
    That's the damn title!

    If you read my first post in the thread [page2?] I actually suggest leaving boo in place - I think it needs more docs/tutorials but might be able to offer a substantially different language option. Plus I think much of U3D's internals are written with it.

Page 3 of 13 FirstFirst 12345 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •