next »

[InfiniteStateMachine]

UnityEngine and System collide? That's not very good

Well, they're in namespaces for a reason (System and UnityEngine are namespaces). c:

They only collide if I decide to "use" them with the using statement (basically the same as using namespace in C++), so they don't collide by default. But Object and Random exist in both (and I only ever use the Unity versions), so on the relatively rare occasion that I need something from System, I just prefix those things with the namespace. Meanwhile I use lots of things from Unity's namespace(s) all the time (not a surprise when that's the engine I'm working in), so I do "use" those.

Note that they're still accessible without the using statements (I just have to specify the full namespace path). C# doesn't usually use anything akin to import or #include; it's just magically available if the parser can find the files.

Ah yes. In that case you might as well just use the fully qualified path of the one you use less.

I was curious and looked up the reason. You can't execute a lambda because you can't infer the type of its parameters (meaning you can't bind a lambda to a var too). Here's a SO which explains the issue : http://stackoverflow.com/questions/6897611/lambda-expression-and-var-keyword-in-c-sharp

One question though. Why would you want to immediately execute a lambda? If you want to do that then why not just write the code normally?

You could always switch to F# :D (I kid, I kid)

[oahda]

For a bit of a silly and suboptimal but potentially more nicely organised and readable reason:

I had a do…while where I wanted a complex condition that had to be expressed by more than one statement, and it seemed like a neat way to make it compact by putting a lambda directly into the while instead of declaring a function somewhere else (which would only be used in one place anyway: this particular loop) and calling it.

It's obviously less optimal to use a lambda than a regular function for a few reasons, but this wasn't critical or often called code, and the condition wasn't expected to stay true for very long anyway (most of the time, it wouldn't even be true once), so I thought it'd be nicer to have it all in one place than to declare some function elsewhere and then only ever use it here in this other part of the code.

 

You could always switch to F# :D (I kid, I kid)

No control over this at work, I'm afraid!

[InfiniteStateMachine]

Heh, I just tried to make what you were trying to do work in a couple different ways. Anonymous methods don't work either :/

I've tried pitching f# at work for a few systems where it would make sense. Obviously not really going to happen. It would certainly make my job secure though! :D :D

[InfiniteStateMachine]

This is the best I could come up with. Not perfect but you won't have to bring in the using statement.

Outside of method :

Code:

delegate bool MyPredicate();

Inside method :

Code:

 ((MyPredicate)(() => { return true; }))();

[oahda]

That requires an external declaration anyway for something that's only used once, so might as well just declare a method with the code in it and call that.

Another option to at least have the code in the same place would've been to separate the lambda from the while but still have them in the same scope, I guess:

Code:

Func<bool> cond = () => { … };

do { … } while(cond());

[InfiniteStateMachine]

Yeah I hear you. I was mainly trying to find a way to avoid bringing in the Func name. I was hoping that maybe I could do a delegate declaration in function scope to eliminate the leak outside the method but the compiler didn't like that :|

In C#7 you can have functions declared inside functions though! I'm guessing that won't be coming to Unity any time soon.


Here's an example from this page (bonus, it also shows the new feature of multiple return values) : https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/

Code:

public int Fibonacci(int x)
{
    if (x < 0) throw new ArgumentException("Less negativity please!", nameof(x));
    return Fib(x).current;

    (int current, int previous) Fib(int i)
    {
        if (i == 0) return (1, 0);
        var (p, pp) = Fib(i - 1);
        return (p + pp, p);
    }
}

[oahda]

Neat! Yeah, as far as I understood (it was talked about in a devlog recently), C# is weirdly held back (perhaps not so much language-wise, but apparently the GC doesn't work as well or something like that?).

That looks neat, tho! Very similar to the upcoming C++ multiple return syntax I showed recently. I don't know if that requires a struct tho, or if it's actually possible to just return comma-separated values like that.

[InfiniteStateMachine]

The underlying type you get back is actually Tuple so it's really just syntactic sugar. 


Last I checked the reason Unity can't move forward is because they were on the Novell license of mono which is very old but doesn't force the end user to pay 1500$ for IOS or Android support. With that version of mono comes a relatively terrible GC from 10 years ago.

Since I checked though, Microsoft bought Xamarin and open sourced .Net so maybe there's hope for the future!

[oahda]

Ah. C# does a lot of that. C++ less, but still some AFAIK. From a language designer's perspective, I don't like it TBH. I don't think a compiler should be aware of user-defined types in a hardcoded way like that, even if they're in a standard library. It feels spaghetty. I think something should be either built in completely or not at all. Seems a lot cleaner. :c

[InfiniteStateMachine]

Yeah I kind of feel that way too. If I had to guess, they might have done it that way because the alternative would involve changing the IL spec and that might break other .net languages.

Who knows though? I could be WAY off :D

[standardcombo]

Unity has done a ton of work on IL2CPP which replaces Mono. It's not 100% complete yet but it's really close. Some people have been using Xamarin but I hear from the Unity devs that IL2CPP is where they want to go for all platforms. This already replaced Mono on iOS as Apple forced their hand through architecture changes.

Can't comment on how user defined types work, but I feel like I have all the tools I need in C#, especially coming from j2me and then Actionscript...

[oahda]

React

Vue seems to be like a nicer, lightweight React that doesn't necessarily come with any overhead or more complexity than a single file to include (but can work with the npm stuff if so desired): https://vuejs.org/guide/

Seems like a much nicer direction for web development to be going.

Also: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.19jqshfa9

[InfiniteStateMachine]

People using .get on unique pointers makes me sad

[standardcombo]

Also: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.19jqshfa9

Funny. Reminds me why I stay away from web development.

[DireLogomachist]

Funny. Reminds me why I stay away from web development.

And me as well.  Everything changes too fast and no one tool is ever sufficient.

[Cheezmeister]

Trying, and failing, to deal with unsynchronisation in ID3. I don't necessarily want to punch whoever dreamed this up, merely whoever is actually using this "feature" in 2016.

[oahda]

People using .get on unique pointers makes me sad

That's what I'm doing after the long discussion we had recently after which it was concluded that I should just pass regular pointers around (for nullability) that are owned (as unique pointers) by someone else. Then this was cemented after watching some of the cppcon talks about ownership and never assuming ownership of a raw pointer and not passing around smart pointers all the time.

So I have the unique pointers in an object and then there are getters to get those by name as regular pointers (because there might not be anything by that name, in which case null is returned), which calls get() on the internal pointer to return the raw one stored in it. All other code knows it does not own regular pointers and won't attempt to modify or delete them.

Maybe that's not the issue you meant tho?

[Dacke]

Also: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.19jqshfa9

Funny. Reminds me why I stay away from web development.

I'm just learning the stuff and I find it pretty great. Developing for browsers has been hell since forever, but I'm seeing the light in the tunnel.

So what I'm hearing is that in 2016 people in the JS community are:
figuring out how to make sure the latest code runs on old browsers, how to add typing, do functional programming (if you want to), figuring out how to do UI state changes in reliable ways, creating central repositories etc.

So not only are they coming up with new ways to make JS bearable, they're also innovating solutions that are better than anything I've previously seen wrt to UI. I think some of the innovations will spread to other languages/frameworks eventually.

[oahda]

Obviously things are building on top of each other and hopefully settling for something nice eventually. It's just this chaotic arms race that we're in the middle of that can be very daunting. As I commented somewhere else, I feel the fundamental ideas are sound, but the execution in practice seems like a hack job. But it seems React and other "reactive" frameworks were on to something, and Vue took it out of the bloated npm ecosystem (unless one wants it) to make it lightweight again. That seems like a good development to me.

[oahda]

OUTRAGED because Mathf in Unity has π but not τ defined.