Hello Folk’s,
I’m curious to know
Does Delegate exist in Scala Or Groovy like C# language or not ?
If your answer is no please explain
Why the modern languages like Groovy , Scala , … does not support it like C# ?
Why mcse dynamics has accepted it, but others not ? So should not it be useful ?
Thanks
As far as I know delegate is just a silly name for something that wants to be a first-class function. Scala has first-class functions without the need for weird keywords:
def foo(s: String): Int = s.length
def bar(f: String => Int): Int = f("bazz")
bar(foo) // 4
Right – Scala doesn’t need Delegates because that capability is built into the heart of the language. (Delegates were added to C# because C# was originally Java, which had no such concept.)
@gnanasekar6914 Don’t get too distracted by names. It’s very common for the same idea to be represented by different names (and often different syntax) in different languages. C# is the only language that has “Delegates”, but many languages have the same functionality under different names…
Yep, different languages name similar ideas with different words. For example typeclass in Haskell is very similar to trait in Rust (and someone told me it’s also similar to protocols in Swift - I haven’t verified that). In Scala we also have traits, but Scala’s trait is in turn most similar to Java interface. Therefore a concept name should be considered in context of the programming language it’s taken from.
I don’t know if it was in this forum or another one I go to, but someone brought up a good point–if you come to a software forum and want to ask about some missing feature (as you see it), then you have to justify why the feature should be added; the software project shouldn’t have to justify to you why the feature wasn’t or shouldn’t be added. The project is the incumbent and the discussion host; you are the guest.
Given that, why do you think delegates should be added to Scala? 
@yawaramin I don’t think that’s entirely fair here. This is the Users forum, and is very explicitly for new folks; while the wording of the original question may have been a hair strident, I think the question is entirely reasonable. And in fact the answer is that Scala does have the desired functionality – it’s just expressed in a different way.
I’d agree with your point if it was over on Contributors. But here, I think it’s more appropriate to interpret questions as questions unless they’re a lot more hot-headed than this…
Agreed. I’ll also add that at least IMHO, questions about why something
isn’t a feature are just as valid and worth asking as ones about why
something is. Both get at the design of a language and the tradeoffs
it makes.
Scala has first class functions.
First class functions differ from delegates in C# in an important way: a delegate has to be declared to be some delegate type, and delegates of different types are not “compatible”.
Many people consider that an unfortunate choice (I think I’ve read Anders Hejlberg and Eric Lippert decry that choice).
An other way to look at it is as if the only delegate types in scala are the Func<> delegates, so they’re all compatible.
That’s a bit simpler than the C# situation where you have the closely related concepts of
A lambda expression, which is an expression: e.g. (int x) => x * 2
Depending on the context, this is interpreted either as an anonymous function, which can be assigned to a delegete type of the correct signature, e.g. when you have
public delegate int MyDelegate1(int x);
public delegate int MyDelegate2(int x);
MyDelegate1 del1 = (int x) => x * 2;
MyDelegate2 del2 = (int x) => x * 2;
Func<int, int> del3 = (int x) => x * 2;
//but not
//MyDelegate1 nuhuh = del2 //does not compile, del2 of type MyDelegate2
//does not conform to type MyDelegate1
But it could also remain an expression:
public delegate int MyDelegate1(int x);
public delegate int MyDelegate2(int x);
public Expression<MyDelegate1> = (int x) => x * 2;
public Expression<Func<Int, Int>> = (int x) => x * 2;
in which case you only have the expression which isn’t compiled to a function yet, and might be translated to something else (e.g. an SQL statement in LINQ to SQL).
This feature is really neat and also really scary - I’m not sure which one it’s more yet.
In scala, the situation is much simpler. (x: Int) => x * 2 is just a Function1[Int, Int], regardless of context, and any Function1[Int, Int] is of the same type as any other Function1[Int, Int].
I don’t know groovy, so I can’t comment on that.
Since 2.12 that lambda could also be some Foo where Foo has a Single Abstract Method.