Delegate Notes 1: Instantiation of non-lambda delegates

This entry is primarily a note for myself, but it might come in useful for others if they stumble across it.

When creating a delegate, you use something similar to the following code:

NOTES:

1: Delegates are declared with the same method signature as the function they’re referring to.
2: Delegates act as types. The delegate name that you assign is the “Type” of the delegate.

(In this example, the “Type” is “dello”)

A delegate is NOT a class or method or instance.


To use the delegate, you must:

A: Declare the delegate using the keyword “delegate”.

Remember – use the same method signature as the function to which you are pointing.

In this case we are pointing to a function with the signature “void hello()”.

Since we are calling our delegate/type “dello” we use that for the name.

B: Create an delegate instance by using the delegate name as the type of the delegate.

C: Assign the function via the ‘=’ operator to the delegate instance (not the type).

The following will NOT work (here you are using the name of the delegate type, not the instance of the delegate):

D: Do NOT use the parens after the function name of the function you are pointing to.  The following will NOT work.

E: The form of assignment using the equals operator is syntactic sugar for the following, as of version 4.x of C#, previous versions you have to use the style listed below.

 

Hahaha – you thought it’d be easy. You should know better by now!

Sure, he says. Sure instead of creating a test project in Unity to do some tests with delegates (instead of fucking up his main code), he decides to just do a plain C# code, which entails downloading the latest Xamarin (dunno why – he could just as easily use the Mono he has with Unity, but he wants the latest and greatest, I guess)…
So Xamarin Studio is installed, oh yay! He fires it up, tells it to create a console app and it works well. “Hello World” is just fine.

OK, let’s make a little method inside this class. non-static method, yada yada. Hey I think I’ve seen this in Unity before, I can’t recall what resolved it… Lemme look around a bit. Oh, yeah, I have to instantiate the object before I can call its method… Oh… Shit.

This means I have to remember how to create a constructor.

Unity took care of all that shit with its base “GameObject” or “ScriptableObject” classes and prefab system, I never had to create a constructor of any time. That’s great for Unity, but it’s kind of cheating and not helping me learn C# in general. So I guess time to dig in and work on constructing objects and calling methods on them. It’s been like 5 years since working in C/C++ and with that I sucked. Let’s see if I can adapt quickly to this in C#.

And I thought this was gonna be easier than just trying it in Unity. I could try it in Unity, still, but I think I really wanna do it at the ground level to really understand what I’m doing which means doing it in C# standalone, with only the base System.

Delegates, Events, Practice/Learning

So – so far, when I’ve been trying to learn something new, I’ve been doing it directly in my code. I think that has had the side-effect that I have been hesitant to try new things because of being afraid of fucking up my code. This is dumb thinking (especially if I properly backup and use source control – which I *have* been doing since my screwup on that little number last time), but it can still be something to think about.

When learning things, sometimes it’s best to strip down the complexity and really focus on the core concept.

I’ve been looking at tutorials and text regarding delegates and events in C#. Conceptually it’s fairly simple. But implementation is a little more complex than I would think, and therefore, that complexity, combined with adding it to my already existing code (which adds yet more complexity) meant that I’ve been afraid to dig in (it doesn’t help when I have been working lots of overtime at my 9-5 job and just want to be braindead after work).

Between realizing that I can test code without having to deal with Unity directly, along with some advice I gave a C programmer on reddit last night about not diving in too deep, and stepping back the complexity of something while you try to learn, made me realize that I should work directly in C# with some sample delegates and events that don’t utilize the Unity framework, and once I fully grok the concept then could even, hopefully, get some template/scaffolding code that I could plop into the larger framework of the game (and just modify as needed)…

Take my own advice. Sometimes, that’s the way forward, it’s easy to sit there and give wise advice to others (well, if you’re being rational and not just being opinionated about stupid shit, which, admittedly, is 90% of the time for most people, including myself)… But it’s good to perhaps step outside your own self, and give yourself the advice you might give to someone else.

When you ask “How should I approach this?” don’t answer for yourself, answer as if someone is asking you that question, and having that separation might make the pressure of finding an answer more clear and give you some insight that you might not really have gotten if you’re stuck nose down in your own ego.