Which language are we talking here? Cpp? Because typeof hasn’t ever seemed useful to me in how I use cpp or how I have ever really used a language. I also remember it being criticized in java class more than 20 years ago when OOP was solely preached, even for scientific people like me.
This sure looks like C#. I use typeof every once in a while when I want to check that the type of a reference is a specific type and not a parent or derived type. But yea, really not that often.
If you declare a class Pie<T>{} then attempt to call typeof(Pie<T>) or typeof(T) it won’t even build because you failed to specify what type T is. typeof(Pie<object>) would work but that just returns “Pie1[System.Object]”.
I have used typeof(T) inside the generic class, so fx a function inside the classPie where T can be refered.
But out of context, if you were to call typeof(T) inside Program.cs’s main function, it would not work.
Yeah, but to do that you’d need an instantiated instance of the Pie class, which would answer in the context of the generic type parameter, not the whole Pie class.
This is too funny. Everyone here, me included, is profoundly overthinking this, lol.
TypeScript has all of these patterns, they are used very frequently and they are necessary because TypeScript tends to be interesting from time to time since its types only exist at compile time, because it compiles to JavaScript, which is a language without types.
TypeScript also allows any as a keyword, which says “I don’t know which type this is and I don’t care”, which still produces valid JavaScript. To get back to typed variables it is necessary to use typeof (or similar constructs like a type guard).
Given the callout as a mixin, you’re probably right. Other languages have them, but I’ve only heard something described in practice as a mixin working in Angular and Typescript. (Neither of which are my forte, so if I’m wrong, I’m wrong.)
I’m not shy about using typeof for logging when it’s appropriate. Anything braver than that and you’re probably getting into reflection, which also means you’re probably not writing the code the way you should.
Your assumption that “using reflection means the code is wrong” seems a bit extreme, at least in .Net. Every time you interact with types, you use reflection. Xml and Json serialization/deserialization uses reflection, and also Entity Framework. If you use mocking in test you are using reflection.
We have an excel export functionality on our sites that uses reflection because we can write 1 function and export any types we want, thanks to reflection.
I said “probably”. I’m not out here blacklisting a useful tool. That would be ridiculous. If you found a situation where it was appropriate, great, more power to you. Those cases definitely exist.
A good sense of “code smell” is one of the most valuable programming skills. I think your “probably” is justified: if you’re doing X, you should look twice at how you’re doing it. Maybe it’s right, but usually it’s not, so it’s worth a pause and a thought.
huh, you’re right!
I’m trained on a different kind of code. In C# in particular, which I use mostly to do sneaky stuff (patch/inject runtime code to, um, “fix” it) and when I see a project that it’s too clean it smells
I also see python code (I code regular stuff in it) that could be written much more cleanly using monkey-patching
Hm, I’m currently working on a project with a ton of runtime-configurable plug-ins and dependencies between them. All of that is held together with a copious amount of black QMetaObject magic.
I had the same thought about it, but I’m not sure how you’d get similar functionality without reflection and not making it even more convoluted and fragile…
Metaprogramming is extremely useful for long term code readability. What you’re doing is probably fine but we can’t really evaluate that without seeing the actual code.
Which language are we talking here? Cpp? Because typeof hasn’t ever seemed useful to me in how I use cpp or how I have ever really used a language. I also remember it being criticized in java class more than 20 years ago when OOP was solely preached, even for scientific people like me.
This sure looks like C#. I use typeof every once in a while when I want to check that the type of a reference is a specific type and not a parent or derived type. But yea, really not that often.
It looks exactly like c++ and c# and java and probably others.
But neither c++ or Java have typeof
Java only has
instanceofandgetClass, not typeof.Probably because Java and C# take much inspiration from C++. They aren’t called “C-based” languages for nothing 😉
Typescript! Though it’s less useful, since the Typescript types aren’t available at runtime, so you’ll just get
objectfor non-primitive values.It can’t be actual C#, but it does look like it.
If you declare a class Pie<T>{} then attempt to call typeof(Pie<T>) or typeof(T) it won’t even build because you failed to specify what type T is. typeof(Pie<object>) would work but that just returns “Pie
1[System.Object]”.I have used typeof(T) inside the generic class, so fx a function inside the
class Piewhere T can be refered. But out of context, if you were to call typeof(T) inside Program.cs’s main function, it would not work.Yeah, but to do that you’d need an instantiated instance of the Pie class, which would answer in the context of the generic type parameter, not the whole Pie class.
This is too funny. Everyone here, me included, is profoundly overthinking this, lol.
This is likely referring to TypeScript.
TypeScript has all of these patterns, they are used very frequently and they are necessary because TypeScript tends to be interesting from time to time since its types only exist at compile time, because it compiles to JavaScript, which is a language without types.
TypeScript also allows
anyas a keyword, which says “I don’t know which type this is and I don’t care”, which still produces valid JavaScript. To get back to typed variables it is necessary to usetypeof(or similar constructs like a type guard).https://www.typescriptlang.org/docs/handbook/2/typeof-types.html
Given the callout as a mixin, you’re probably right. Other languages have them, but I’ve only heard something described in practice as a mixin working in Angular and Typescript. (Neither of which are my forte, so if I’m wrong, I’m wrong.)
I’m not shy about using typeof for logging when it’s appropriate. Anything braver than that and you’re probably getting into reflection, which also means you’re probably not writing the code the way you should.
Your assumption that “using reflection means the code is wrong” seems a bit extreme, at least in .Net. Every time you interact with types, you use reflection. Xml and Json serialization/deserialization uses reflection, and also Entity Framework. If you use mocking in test you are using reflection.
We have an excel export functionality on our sites that uses reflection because we can write 1 function and export any types we want, thanks to reflection.
I said “probably”. I’m not out here blacklisting a useful tool. That would be ridiculous. If you found a situation where it was appropriate, great, more power to you. Those cases definitely exist.
A good sense of “code smell” is one of the most valuable programming skills. I think your “probably” is justified: if you’re doing X, you should look twice at how you’re doing it. Maybe it’s right, but usually it’s not, so it’s worth a pause and a thought.
huh, you’re right! I’m trained on a different kind of code. In C# in particular, which I use mostly to do sneaky stuff (patch/inject runtime code to, um, “fix” it) and when I see a project that it’s too clean it smells
I also see python code (I code regular stuff in it) that could be written much more cleanly using monkey-patching
Hm, I’m currently working on a project with a ton of runtime-configurable plug-ins and dependencies between them. All of that is held together with a copious amount of black QMetaObject magic. I had the same thought about it, but I’m not sure how you’d get similar functionality without reflection and not making it even more convoluted and fragile…
Metaprogramming is extremely useful for long term code readability. What you’re doing is probably fine but we can’t really evaluate that without seeing the actual code.
I will fight for your right to party.