tag:blogger.com,1999:blog-18241482.post8574016648288073147..comments2023-05-28T03:33:10.735-07:00Comments on Programming and Debugging (in my Underhøøsen): D-elegating ConstructorsCristachehttp://www.blogger.com/profile/08287129746971472910noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-18241482.post-83295108191759963612009-03-26T14:06:00.000-07:002009-03-26T14:06:00.000-07:00As far as delegating constructors goes, you could ...As far as delegating constructors goes, you could take your 'boolean' logic and extend it further using a state-machine type method. You could do simple code-flow analysis to get an idea of the constructor chain. Based upon this, you could assign each constructor an identifier, using the code-flow analysis from before, you'd know in what cases each could possibly be invoked by, so you could emit check code for the cases where certain fields aren't assigned. <BR/><BR/>The only issue with this is the optimization to avoid redundancy might be mitigated by jumping through the individual field initializations, since it would likely be reduced to a series of jump tables based upon the overall complexity of the chain(s).<BR/><BR/>There also might be cases where it's inappropriate to avoid such redundancies. Such as when the initializer is dependent upon incrementing a static value which represents the Identifier of the element, while assigning it later would alter the value, they might, for some unknowable reason, rely on that as some sort of instance counter. To find that their assignment is omitted, in lieu of a parametered constructor that assigns the value, might confuse them a little.Anonymousnoreply@blogger.com