|
Why, just yesterday, I wrote an extension method which fiddles about in the private parts of a .net class.
This is how it's done when Microsoft makes things too elephanting rigid.
The alternative would be to reinvent this particular wheel, which would very likely kill performance.
|
|
|
|
|
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?! 
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?
|
|
|
|
|
I've developed frameworks, and it's virtually impossible to anticipate all user requirements. At least I was dealing with in-house frameworks, where it was easy to interact with users and quickly respond to their needs. For the kind of things that Microsoft is providing, I'm not at all surprised that what you're doing is occasionally necessary.
|
|
|
|
|
Greg Utas wrote: I've developed frameworks, and it's virtually impossible to anticipate all user requirements.
This is the fundamental flaw with all frameworks. Despite it's name the dotNet Framework isn't so much a framework as it is a collection of useful and related classes. It's more of an OS level API for most programmers.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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<typename T> 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 A will take any class "of a type" that exposes a public foo() 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 needed
Greg 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
modified 27-Mar-21 21:38pm.
|
|
|
|
|
Your first example makes sense. Instantiating the second A<B> will fail when it tries to resolve B::foo. It's like A is defining an interface that its template arguments must support.
Not linking dead code into an .exe is great. It allows my main() to #include the 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.
|
|
|
|
|
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
|
|
|
|
|
you should probably refresh. my first several edits were a mess. code was bad. i'm out of coffee. 
Real programmers use butterflies
|
|
|
|
|
I gathered that, and refreshed. If I had coffee now, we'd be here all night.
|
|
|
|
|
Hang the perpetrator from the nearest lamp post, pour encourager les autres! 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Damn good way to wreck production code when the originator changes the way his code works internally - which is why such things are private, obviously.
I'm hoping he deploys at 17:00 on a Friday ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
To paraphrase Frank Zappa, you shouldn't let just anyone spew on your private parts.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Using Visual Studio 2019:
When I write code for an article, I write the article in an html file that lives in the project itself. As I progress, I eventually want to see what the article looks like in the browser. In .Net Framework projects, this works fine, but in .Net Core projects (in this instance, it was a .Net Core 3.1 project), the menu item "View in browser" does not exist in the context menu for the file.
Why would that be?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
This is interesting. I created a VStudio 2019 -- ASP.NET Core project.
I added a basic.html page to the project in the Views\Home\ folder.
I do have the context menu item "View in browser (firefox)".
However, when I attempt to load the page it loads the URL in my browser but doesn't display the page (probably due to routing issue). The URL in the browser looks like : http://localhost:49464/Home/basic which is incorrect. It should have the .html.
Also I do have UseStaticFiles() in my startup.cs.
EDIT
I moved the .html file out to the root (not under views) and now I have the context menu item in 2019 and it actually loads the page now. It was a routing issue in the previous attempt.
|
|
|
|
|
Mine is a Core 3.1 project. I wonder if that makes a difference...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
|
Mine isn't a web app - it's WPF.
EDIT ============
I don't see anything in your settings that's different from mine, excpet mine says "Windows Application" where yours says "Console Application".
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Well, this only took me 24 hours to respond...
But anyways, you are correct if it is a WPF app you won't see that context menu.
Check this snapshot out -- top of Visual Studio : https://i.stack.imgur.com/ozTUB.png[^]
Whether it is wrong or right Studio removes the contextual stuff related to web server and web browser when the app isn't a web project.
Compare that first one to this one (which was my previuos web app)
See the IIS Express choice at the top ==> https://i.stack.imgur.com/sCewp.png[^] .
Not great, but just the way VStudio works I think.
|
|
|
|
|
Does the behavior change if you mark the file "Build action: None", or exclude from project? That might be sufficient to tell Studio to display it using the default browser rather than something dependent on what the rest of the project is doing.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
