The Infinite Extensibility Engine

The biggest issue facing developers today is not lack of OO knowledge, patterns, or guidance.  It’s a sad lack of extensibility in today’s frameworks.  Over the past year or so, getting familiar with ASP.NET MVC, I think I’ve found an answer to the lack of extensibility in not just application frameworks, but the .NET Framework in general.

What’s been holding me back are the moronic constraints of “method signatures”.  Every time I might need an extra parameter, that maybe someone might have passed in, I have to change the signature!

No more.

Enter the Infinite Extensibility Engine Interface, pronounced “eye-ee-ee-eye”.  And it’s just one awesome interface:

public interface ICanTasteTheAmazing
    Dictionary<string, Dictionary<string, object>> Smurf(
        Dictionary<string, Dictionary<string, object>> @it

Yes.  Drink it in.  Taste the amazing.

I came up with this brilliant interface while delving in to the depths of ASP.NET MVC, whose liberal use of hashes and “anonymous types as hashes” is nothing short of breathtaking.  But why be limited to one or two groups of dictionaries per call?  Time to kick it up to 11.  Dictionaries of dictionaries, in and out.

Don’t like what you see?  Pass something else in.  Need something else from callers?  Just go ahead and look for it.  They’ll figure it out.  Eventually.

Naturally, to protect the order of the universe, we’ll create a W3C certified spec to standardize top-level keys, the bucket-of-bucket lookups.  Look for it soon sometime in 2020.  Until then, keep an eye out for the book, audio tape, and speaking tour in your city soon!

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Misc. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Jimmy, I knew your 300th post on Los Techies was going to be amazing!! ;)

  • For extra-extra extensibility, make sure that you use significant keys and values that the publisher and consumer must both parse correctly, for example “implOf(SomeKey)” or “”

  • When will the tooling be ready? I assume there will be a visual designer with code gen?

  • I know that you’re kidding here, but I went on a job interview once where they showed something similar to this that was the Engine That Ran The Company. They never wanted to break an interface contract, so instead you would call the Engine method with the actual command you wanted as a string and the parameters for the call as an array.

    I remember getting a stern email from their hiring manager a few days later to the tune of “why don’t you take us up on this once-in-a-lifetime offer”?

  • LOL! I laughed my ass off. ICanTasteTheAmazing can be implemented by a runtime too! Hello ICanTasteTheAmazing Scheme.

  • Hilarious! But seriously, I hope you never have to do any serious Ruby programming. :-) Then you’ll look back on this post and think, man, why did I hate hashes so?

    As for the name of the interface, well, I’m already trying to dream up ways in which I can sneak that into a codebase. Good stuff man.

  • @Tim

    Yes, and lucrative consulting contracts as well. I’m trying to follow the Oracle model.


    And what was your answer? :)


    I’m thinking instead of a “contract enforcer” in static languages, a “contract negotiator”, where caller and callee compromise and fuzzy match buckets.

  • The development community isn’t ready for such awesomeness.

    Hilarious :)

  • @bogard

    I told them thanks but no thanks. I had a job at the time, and though it was not so great, at least I wasn’t feeding The Engine.

  • This is the best thing ever invented since inward singing!

  • I detect a hint of sarcasm…

    Just a hint…


  • That’s a very elegant example of Greenspun’s Tenth Law. You should submit it to the authors of “Beautiful Code” for their next edition.

  • There an RDBMS equivalent of this design. Single table with ID, ParentId and Value. I invented it back in 1999.

  • AT

    So way back in the day I was using Groovy, and they had named parameters. Which was great. Then they dropped support for named parameters. Sort of. You could still use them in a call, but the called function would just get a dictionary that it had to parse. Naively, I rewrote the functions to work with the dictionaries that they were now getting. I still consider that one of my bigger programming mistakes.

  • @ZVolkov

    Wow. You win.


    Mistake….or triumph?

  • Forget string keys, this is even more extensible if you allow any object type for keys.


    With this improved approach, you can even use a dictionary as a key to another dictionary.

    Now THAT’S Infinite Extensibility!