• (nodebb)

    Well, at least they avoided reflection ... so there's that.

    They also avoid a little known OOP principle called polymorphism but eh, I get it - when you hear composition over inheritance then you just have to end up with something like this :-)

    Addendum 2024-04-08 06:36: Clarification for non-developers: public interface ICallable { public Phone { get; } }

  • (nodebb)

    My guess would be that they wanted to avoid KeyNotFoundException if the key doesn't exist. So, we iterate key-by-key to find what we want! Completely ignoring Dictionary<TKey,TValue>.TryGetValue(TKey,out TValue).

  • Steve (unregistered)

    This is just a difference in a person’s philosophical beliefs. Do I find a solution that works or do I look to understand the high-level language and what methods are available to solve the problem? Everybody here is part of the latter thinking, but certainly not our entire career. Honest poll - when in your career did you turn from just searching SO and “finding a solution” to digging in to understand the technology? For me, it was about 4-5 years in…after having to fix bad code from other devs.

  • (nodebb) in reply to colejohnson66

    Nah, that's what he tried to do:

    public sealed class Entity
{
  public string? Contact
  {
	get => _ptAttribute switch
	{
	  "mail" => _email,
	  "facsimiletelephonenumber" =>_faxNum,
	  "telephonenumber" => _phoneNumber = value,
	  _ => null
	}
	
	set
	{
		switch(_ptAttribute)
		{
		  case "mail": if(string.IsNullOrEmpty(_email)) _email = value; break;
		  case "facsimiletelephonenumber": _faxNum = value; break;
		  case "telephonenumber": _phoneNumber = value; break;
		}
	}
  }

  private string? _ptAttribute;
  private string? _email;
  private string? _faxNum;
  private string? _phoneNumber;
}

    Keep in mind, there's still a lot wrong with this code, like magic strings and a lot of undefined cases ending in null (not clear from the article), so this is something I would make 1:1. However if you want avoid inheritance, this would be the way. Otherwise you end up with simple type pattern matching.

    Addendum 2024-04-08 07:57: BTW always use the switch statement/expression instead of Dictionary. The reason is obvious, compared to other languages like Java, .net has low level hashed lookup support with IL SWITCH which is way faster and slimmer and the compiler knows exactly when to use it (for example if you have only a few statements, simple if branches are still the fastest option cause hashing and lookups are not free). https://learn.microsoft.com/en-us/dotnet/api/system.reflection.emit.opcodes.switch?view=net-9.0

  • (nodebb)

    I subscribe to the feed for this site using the subscribe support in Slack for some strange reason. It has notified me of this article 12 times so far.

    ...Make that 13.

    Addendum 2024-04-08 09:43: Against my philosophical principles, I'm going to try switching the subscription from the feed URL the site provides to the Feedburner address it redirects to.

    Addendum 2024-04-08 10:11: That did not fix it.

    Addendum 2024-04-08 10:35: The issue is at least partly on Slack's side (I suppose it's possible there's an issue with the feed entry and Slack's error handling isn't coping with it well, in which case it arguable wouldn't be entirely Slack's failt)...because I removed that subscription in Slack entirely and it's still happening.

  • Naomi (unregistered) in reply to MaxiTB

    Point of order: Java absolutely compiles switches as lookup tables (https://stackoverflow.com/a/22110821). Java's switch has actually gotten really cool over the past few years; at its most advanced, it resembles Haskell's pattern matching.

  • (nodebb) in reply to Naomi

    Thanks for the info - I had no idea that there's now bytecode support for lookups; do you know when those got added?

    Java's switch has actually gotten really cool over the past few years; at its most advanced, it resembles Haskell's pattern matching.

    Ha yeah, well, in .net we have generator since the beginning (https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/statements/yield). When it comes to pattern matching, the .net version has way more features, you chain multiple conditions (https://learn.microsoft.com/en-US/dotnet/csharp/language-reference/operators/switch-expression).

    Now maybe I missed something, was just reading up on: https://docs.oracle.com/en/java/javase/17/language/switch-expressions.html

  • Tim R (unregistered)

    People defending the switch approach seem to have missed this part of the post:

    "The dictionary in question is actually quite large, so we spend most of our time here looking at keys we don't care about, to find the three we do"

    The inefficiency is inside the switch; it's from the looping over every key when the whole point of a dictionary is to provide quick access to named keys

  • MrBerryK (unregistered)

    At least they only iterate the dictionary entry ONCE!

  • (nodebb)
    It's incredibly common to convert objects to dictionaries/maps and back, for all sorts of reasons.

    Which is unfortunate, because most of those reasons don't stand up to scrutiny.

    If you find yourself moving stuff between a strongly typed object and a dictionary, you're most likely doing something very wrong.

  • (nodebb) in reply to Steve

    Honest poll - when in your career did you turn from just searching SO and “finding a solution” to digging in to understand the technology? For me, it was about 4-5 years in…after having to fix bad code from other devs.

    Well, given the precise details of the question, I'm going to say that I never even started "just searching SO", seeing as how it didn't exist before the 19-year mark of my career...

    (Point of amusement: when I began my career, the Web didn't exist even in a rudimentary form...)

  • Randal L. Schwartz (github)

    I oddly see this pattern a lot. Is the concept of a Map not being well taught? The whole point of the data structure is "given a key, give me its value". Yet people spend time iterating over all keys or all key-value pairs. Why?

  • (nodebb) in reply to Steve

    Do I find a solution that works or do I look to understand the high-level language and what methods are available to solve the problem?

    That's pretty easy to answer. If a language solves an issue, the solution that works is the language. If it doesn't but the framework solves the issue, the solution that works is the framework. If it doesn't but there is an package solving the issue, the solution that works is the package.

    Reinventing the wheel is never a solution that works; it's just creating more work and technical debt.

    Honest poll - when in your career did you turn from just searching SO and “finding a solution” to digging in to understand the technology?

    When I was 9 years old I started writing a rudimentary 6502 assembler, because after two years BASIC was no longer enough and I could not afford getting the software. In other words, I doubt a poll like that turns out anything useful - people here are vastly different in their backgrounds and so is the quality of answers on SO ;-)

  • (nodebb)

    I love how they iterate over all the keys, and for each key, they go and look up the corresponding value. Then they work out if they even want that key-value pair. They didn't even iterate over the key-value pairs.

    It's like they wrote it the correct way, then their boss, or perhaps the devil on their shoulder, told them "make it bad". So they did. Then they said "make it worse", again and again.

  • LZ79LRU (unregistered) in reply to Steve
    Comment held for moderation.
  • (nodebb)

    @Mr. TA Ref

    If you find yourself moving stuff between a strongly typed object and a dictionary, you're most likely doing something very wrong.

    In general I'd agree. But ...

    With the huge exception of all the webclient / webserver apps we have to write where everything has to be serialized / deserialized over the wire in some stringly form to get data from here to there. And across languages to boot.

    The amount of collective silliness this causes is simply insane. But we're stuck with this stringly cross-language cross-platform serialization because nobody controls enough of the ecosystem to deliver an end to end solution that avoids all that.

  • exercism-1 (github) in reply to Randal L. Schwartz
    Comment held for moderation.
  • (nodebb) in reply to Steve_The_Cynic

    Similar. I've moved in the opposite direction to which Steve suggests.

    I first programmed for pay as an undergrad 27 years before SO. That first paid language (TUTOR) had a 200-page manual and online help (including context-sensitive help in the program editor back in the early 1980s). Through some reading and practice, one could know most anything.

    For the past decade or so, I've been learning Python (as a chip designer, programming is a small portion of my job) which has proven more difficult. The standard library is gigantic and that doesn't begin to include the larger ecosystem like np, pytorch, matplotlib, etc. For this, SO is invaluable to me when I have something new as it is likely that there is a package I haven't read yet which solves the problem, at least to some degree.

  • Naomi (unregistered) in reply to MaxiTB
    Comment held for moderation.

Leave a comment on “They Key To Dictionaries”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article