Absolutely Horrific
-
Reaching for Private Parts - The Daily WTF[^] Modifying a class using reflection only in production... :eek:
What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???
1- the link refers to Java, not .Net. MS has nothing to do with this. 2- if this fragment is required, the developer is doing it wrong. He is using the wrong class for the wrong job or has not properly configured the app ( a cache in this case) 3 - the class is defective, perhaps one of 100 open-source jars to choose from, perhaps another “vendor” is in order 4- is this H1-B code? That would explain it.
-
PIEBALDconsult wrote:
I wrote an extension method which fiddles about in the private parts of a .net class.
There may be (extremely rare) cases when such perversions may be necessary, but a difference in behaviour between development and production?! :wtf: Isn't the whole idea of a development environment to be as close as possible to the production environment, but without changing production data?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Shouldn't there be a test database (recent copy of the production database) to test code against?:confused:
-
Another flaw with frameworks is a monotonic increase in their surface-to-volume ratio. It stems from a reticence to introduce "breaking changes" when evolving the framework, because existing users who want to migrate to the next major release think it should be transparent. I have no sympathy for them. To me, a framework embodies a powerful object model, which means that it must typically be used as a whole, whereas a library is a collection of disparate classes whose collaborations are up to the user.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.One of the reasons I keep falling in love with C++ over and over again is A) source level polymorphism B) selective linking leading to C) Frameworks that aren't frameworks as long as they aren't coded like garbage What I mean is you can have a bunch of things that all work together (the STL, a framework more than a library considering how many different things it covers, but all the core bits are used together) and you can only include bits you need. This encourages me to code even things that may be used rarely, because if you don't need it it's never compiled in. That leads to very little framework bloat. Plus it's as modular as you develop it to be. If you update <iostream> library you can theoretically, simply update that header as long as you don't change exiting source level interfaces
Real programmers use butterflies
-
One of the reasons I keep falling in love with C++ over and over again is A) source level polymorphism B) selective linking leading to C) Frameworks that aren't frameworks as long as they aren't coded like garbage What I mean is you can have a bunch of things that all work together (the STL, a framework more than a library considering how many different things it covers, but all the core bits are used together) and you can only include bits you need. This encourages me to code even things that may be used rarely, because if you don't need it it's never compiled in. That leads to very little framework bloat. Plus it's as modular as you develop it to be. If you update <iostream> library you can theoretically, simply update that header as long as you don't change exiting source level interfaces
Real programmers use butterflies
Please elaborate. I think I might learn something. Source level polymorphism? Never heard of source level as an adjective for polymorphism. What's it mean? Selective linking? By this, do you mean that code that isn't used doesn't get linked into the .exe? I see the STL as being in a half-world between library and framework. Iterators, for example, cut across many of the classes, but the higher-level classes stand on their own. That's quite different from what I'm doing, where it's impossible to use any component on its own, because those in the same static library use each other freely. When I read about this dependency injection fetish in light of what I'm doing, I just throw up my hands and chortle at the endless boilerplate that would be needed. Besides, toy test harnesses will never exercise a framework as well as a few serious applications.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Please elaborate. I think I might learn something. Source level polymorphism? Never heard of source level as an adjective for polymorphism. What's it mean? Selective linking? By this, do you mean that code that isn't used doesn't get linked into the .exe? I see the STL as being in a half-world between library and framework. Iterators, for example, cut across many of the classes, but the higher-level classes stand on their own. That's quite different from what I'm doing, where it's impossible to use any component on its own, because those in the same static library use each other freely. When I read about this dependency injection fetish in light of what I'm doing, I just throw up my hands and chortle at the endless boilerplate that would be needed. Besides, toy test harnesses will never exercise a framework as well as a few serious applications.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Greg Utas wrote:
Never heard of source level as an adjective for polymorphism. What's it mean?
It means if I have a template
template struct A {
T t;
A() : t() { t.foo(); }
};Then this will compile
struct B {
void foo() { printf("hello!\r\n"); }
};A<B> c;
but this won't:
struct B {
void bar() { printf("goodbye!\r\n"); }
};A<B> c;
template
Awill take any class "of a type" that exposes a publicfoo()method. This allows you to create a kind of polymorphism at the source level. There is no explicit binary contract like there is with traditional polymorphism. It's a source contract. You don't actually need a binary interface to be fulfilled for the class. The bottom line is, you don't inherit to do it. You just call the methods you need. It works because templates aren't resolved until they are instantiated. One of the chief advantages of this over traditional inheritance based polymorphism is that there's no source dependency on a base class. Most of the STL does it this way, preventing much of the cross header dependencies that would otherwise be neededGreg Utas wrote:
By this, do you mean that code that isn't used doesn't get linked into the .exe?
Yes. I don't know if there's a better name for it, that's just what i've always called it. It's so critical for so much of what i do in C++. My code I'm writing would be so not viable without it.
Real programmers use butterflies
-
Please elaborate. I think I might learn something. Source level polymorphism? Never heard of source level as an adjective for polymorphism. What's it mean? Selective linking? By this, do you mean that code that isn't used doesn't get linked into the .exe? I see the STL as being in a half-world between library and framework. Iterators, for example, cut across many of the classes, but the higher-level classes stand on their own. That's quite different from what I'm doing, where it's impossible to use any component on its own, because those in the same static library use each other freely. When I read about this dependency injection fetish in light of what I'm doing, I just throw up my hands and chortle at the endless boilerplate that would be needed. Besides, toy test harnesses will never exercise a framework as well as a few serious applications.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Greg Utas wrote:
Never heard of source level as an adjective for polymorphism. What's it mean?
It means if I have a template
template struct A {
T t;
A() : t() { t.foo(); }
};Then this will compile
struct B {
void foo() { printf("hello!\r\n"); }
};A<B> c;
but this won't:
struct B {
void bar() { printf("goodbye!\r\n"); }
};A<B> c;
template
Awill take any class "of a type" that exposes a publicfoo()method. This allows you to create a kind of polymorphism at the source level. There is no explicit binary contract like there is with traditional polymorphism. It's a source contract. You don't actually need a binary interface to be fulfilled for the class. The bottom line is, you don't inherit to do it. You just call the methods you need. It works because templates aren't resolved until they are instantiated. One of the chief advantages of this over traditional inheritance based polymorphism is that there's no source dependency on a base class. Most of the STL does it this way, preventing much of the cross header dependencies that would otherwise be neededGreg Utas wrote:
By this, do you mean that code that isn't used doesn't get linked into the .exe?
Yes. I don't know if there's a better name for it, that's just what i've always called it. It's so critical for so much of what i do in C++. My code I'm writing would be so not viable without it.
Real programmers use butterflies
Your first example makes sense. Instantiating the second
A<B>will fail when it tries to resolveB::foo. It's likeAis defining an interface that its template arguments must support. Not linking dead code into an .exe is great. It allows mymain()to#includethe subset of static libraries that are wanted in a build, which omits all the others without any fuss at all. It's gross to contemplate the code bloat that would otherwise occur.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
you should probably refresh. my first several edits were a mess. code was bad. i'm out of coffee. :laugh:
Real programmers use butterflies
I gathered that, and refreshed. If I had coffee now, we'd be here all night. :laugh:
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Your first example makes sense. Instantiating the second
A<B>will fail when it tries to resolveB::foo. It's likeAis defining an interface that its template arguments must support. Not linking dead code into an .exe is great. It allows mymain()to#includethe subset of static libraries that are wanted in a build, which omits all the others without any fuss at all. It's gross to contemplate the code bloat that would otherwise occur.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.I'm glad it made sense to you. It wouldn't have compiled, but it conveyed the idea, it seems, because you're exactly right about how it works. And it's bril, because you don't need to include a header for a common base to use it. I agree with you about the linking. I write a lot of IoT code, and i couldn't without it.
Real programmers use butterflies
-
Reaching for Private Parts - The Daily WTF[^] Modifying a class using reflection only in production... :eek:
What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???
Building a web scraper I had the pleasure to abuse JavaFX's WebView browser module by modifying byte code to hook onto http requests and the trick of this post to get at the url in an intercepted UrlLoader call. I wouldn't care using it in production. But also in test, I'd like to mention.
