this post was submitted on 24 Sep 2024
121 points (94.2% liked)

Programmer Humor

19623 readers
5 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 

Source

Alt text:A screenshot from the linked article titled "Reflection in C++26", showing reflection as one of the bullet points listed in the "Core Language" section

you are viewing a single comment's thread
view the rest of the comments
[–] JakenVeina@lemm.ee 43 points 2 months ago (2 children)

It's the capability of a program to "reflect" upon itself, I.E. to inspect and understand its own code.

As an example, In C# you can write a class...

public class MyClass
{
    public void MyMethod()
    {
        ...
    }
}

...and you can create an instance of it, and use it, like this...

var myClass = new MyClass();
myClass.MyMethod();

Simple enough, nothing we haven't all seen before.

But you can do the same thing with reflection, as such...

var type = System.Reflection.Assembly.GetExecutingAssembly()
    .GetType("MyClass");

var constructor = type.GetConstructor(Array.Empty<Type>());

var instance = constructor.Invoke(Array.Empty<Object>());

var method = type.GetMethod("MyMethod");

var delegate = method.CreateDelegate(typeof(Action), instance);

delegate.DynamicInvoke(Array.Empty<object>());

Obnoxious and verbose and tossing basically all type safety out the window, but it does enable some pretty crazy interesting things. Like self-discovery and dynamic loading of plugins, or self-configuration of apps. Also often useful when messing with generics. I could dig up some practical use-cases, if you're curious.

[–] GetOffMyLan@programming.dev 8 points 2 months ago* (last edited 2 months ago)

You can also optimize this a bit.

You can use Activator.CreateInstance instead of reflecting and invoking the constructor.

You can also call MethodInfo.Invoke, you don't need to create a delegate.

Also worth noting that Source Generators have replaced the need for reflection in many cases.

[–] Prunebutt@slrpnk.net 6 points 2 months ago (1 children)

Woah, that's some meta shit. Neat. :D

[–] Zangoose@lemmy.world 8 points 2 months ago (1 children)

It's pretty cool when you use it right but it's also really easy to shoot yourself in the foot with, even by C++ standards. For example, in other languages (I'm coming from Java/C# which both have it) it lets you access private/protected fields and methods when you normally wouldn't be able to.

There's also a noticeable performance penalty over large lists because you're searching for the field with a string instead of directly accessing it.

For the times it is necessary (usually serialization-adjacent or dynamic filtering/sorting in a table) to use reflection, it's faster at runtime than converting an object to a dictionary/hashmap. However, 99% of time it's a bad call.

[–] BatmanAoD@programming.dev 8 points 2 months ago

If you look at the proposal, this is specifically "static reflection", i.e. compile-time reflection. So it doesn't actually have any of the downsides you mention, as far as I can tell.