You can refactor long argument lists into structs as a "zero cost abstraction". The struct's members will be bound as if they were parameters declared on the method.
It's not all or nothing, you can also do this with a subset of the parameters:
You can also have multiple!
The key to this feature was making it:
- Unambiguous - It should easy to distinguish what comes from the body and what is a parameter surrogate.
- Efficient - Make it as efficient as possible to refactor the argument list without performance overhead.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Let me take you on my @msftorleans journey. Let's say you wanted to define a class that let callers subscribe to an event C#. It could look like this: #dotnet
This implementation uses C# events, but let's be a little more verbose and define the contract for subscribing and unsubscribing callbacks:
Now we store a list of Action for subscribers, and we mutate this list when there's a new subscriber or if one is being removed. Calling DoThing will call each subscriber sequentially.
Now lets make this a little more object oriented and Java like (no shade my java people):
I thought this was common knowledge by now, but software engineers at “big tech” and in some of the major tech hubs in the US makes lots of money. I’d encourage you to look at levels.fyi to see the potential earnings at these companies. #techtwitter#BlackTechTwitter
That said this is about potential. This site doesn’t show how many people exists at these levels, let alone how many underrepresented people exist at some of these levels.
At Microsoft about 5.6% (query.prod.cms.rt.microsoft.com/cms/api/am/bin…) of the population is black and I know, just by looking around that there are a lot fewer in the upper echelons of levels. The percentages are more abysmal the further up the chain you go.
Today we had a meeting about experimenting with a green threads implementation in .NET. More info to come soon, exciting times! #dotnet
For clarity, these are threads managed by the runtime instead of the operating system. The net effect is that you can write synchronous looking code that scales as well as async/await does today.
I'm not sure about using redis as a queue, seems like blocking operations block the connection? Also, when using BROP to monitor multiple queues, you end up shuffling the queue names so the queue at the front of this list doesn't take priority (round robin?)
Or do you spin up multiple connections and balance the queues across them? It's a multiplexing problem (reminds me of HTTP/2).
I'm using System.Threading.Channels and Redis to expose a really nuget IAsyncEnumerable<T> implementation. Then using static interfaces to provide the RedisValue -> T.
Lets talk about events. We want to write some code that reacts when something happens. This pattern exists in many domains from UI programming to IoT to serverless. What do the programming patterns for this look like today in #dotnet and #csharp?
We create a button (imagine this was referenced by a form or some UI component), then hook up an event handler and write to the console when a button click event happens. This is the one of the most popular and idiomatic event handling paradigms in .NET today.
It's existed for years and years in many different programming languages and domains. There may or may not be data associated with these events.