locked
Boilerplate code RRS feed

  • Question

  • Hello,

    I'm thinking of building some generic extensions that will take a way all these null, throw checks and asserts and instead use fluent APIs to handle this.

    I already created a discussion that is mostly me there replying to myself, although admittedly it's not so interesting..  haha :)

    So I'm thinking of doing something like this.

    Shall() - Not quite sure about this one yet
        .Test(...) - Determines whether the contained logic executed without any errors
        .Guard(...) - Guards the contained logic from throwing any exception
        .Assert(...) - Asserts before the execution of the code
        .Throw(...) - Throws an exception based on a certain condition
        .Assume(...) - Similar to assert but calls to Contract.Assume

    Usage: father.Shall().Guard(f => f.Shop())

    The thing is that I don't want these extra calls at run-time and I know AOP can solve this for me, I want to inline these calls directly to the caller, if you have a better way of doing that please do tell.

    Now, before I'm researching or doing anything I wonder whether someone already done that or know of a tool that is doing it ?

    I really want to build something like that and release it to public because I think that it can save a lot of time and headache.

    Update: I'll have to think about it some more and change the API to make the intentions clear and the code more readable.

    I think that the idea is not polished at all.


    Eyal (http://shilony.net), Regards.
    • Edited by Eyal Solnik Tuesday, December 27, 2011 1:37 AM
    Monday, December 26, 2011 10:14 PM

Answers

  • Not exactly the same, but you might want to look at CuttingEdge.Conditions for some inspiration here: http://conditions.codeplex.com/

     

    If you read some of the discussions, you'll see what prompted the large design change a while back (from "something.Requires(" to "Conditions.Requires(something"), which is an interesting read.

     

    Also, I wouldn't worry too much about eliminating method calls at runtime.  Instead, I'd focus on making sure that the method calls are ones that will get optimized away by the JIT compiler.  Just follow the JIT compiler rules for inlining, and you should be fine...  That has huge advantages - you get the same runtime characteristics, but a much nicer design/build time scenario.

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    • Proposed as answer by Lie You Wednesday, December 28, 2011 5:24 AM
    • Marked as answer by Eyal Solnik Wednesday, December 28, 2011 1:27 PM
    Monday, December 26, 2011 11:46 PM

All replies

  • Not exactly the same, but you might want to look at CuttingEdge.Conditions for some inspiration here: http://conditions.codeplex.com/

     

    If you read some of the discussions, you'll see what prompted the large design change a while back (from "something.Requires(" to "Conditions.Requires(something"), which is an interesting read.

     

    Also, I wouldn't worry too much about eliminating method calls at runtime.  Instead, I'd focus on making sure that the method calls are ones that will get optimized away by the JIT compiler.  Just follow the JIT compiler rules for inlining, and you should be fine...  That has huge advantages - you get the same runtime characteristics, but a much nicer design/build time scenario.

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    • Proposed as answer by Lie You Wednesday, December 28, 2011 5:24 AM
    • Marked as answer by Eyal Solnik Wednesday, December 28, 2011 1:27 PM
    Monday, December 26, 2011 11:46 PM
  • Well, I again, came to conclusion that what I'm trying to do while might be a good idea in practice is useless or just as bad.

    Null References: The Billion Dollar Mistake

    I'm moving on haha... :)


    Eyal (http://shilony.net), Regards.
    Tuesday, December 27, 2011 3:42 AM