On 11/7/13 4:35 PM, "OmPrakash Muppirala" <[email protected]> wrote:
>On Thu, Nov 7, 2013 at 2:18 PM, Alex Harui <[email protected]> wrote: > >> FWIW, I was thinking that this kind of check should be replaced by some >> capability in the tool chain to verify a configuration, maybe by marking >> some values as required. In production, you hopefully don't need these >> kinds of checks. I've also floated the idea of "debug-mode" beads which >> have more checks than production beads. >> >> Thoughts? >> > >Personally, I don't like the idea of setting the bead values in CSS. It >makes it hard to enforce these kind of things. Ideally, the absence of a >bead that the code is looking for should generate a compile error. > >Another way to inject beads would be to use metadata attributes. >Something >along the lines of spark skins' [SkinPart(required="true")] metadata >attribute. Would this make it easier to do the checks? That would help with the check, but are you also proposing naming the default value in the metadata? > >Or more simpler, maybe we have default empty IBeads available so that >things at least don't blow up. But I am guessing that this approach might >only delay the blow up of the code to a later stage. I guess I'm wondering how easy it is to screw up your config such that we need a lot of runtime protection for this. How did you get into this error in the first place?
