Yeah, it can get tricky with the problems you described. Also if I understand your suggestion, another problem is that you would need to have all the same signature of constructors in FooTC as exist in Foo. I'm assuming that there would be one of these synthetic methods created for each constructor present in FooTC, and called from the appropriate Foo constructor. I'm starting to confuse myself :-)
It's also not clear what to do with the arguments to super(..) in the FooTC constructor -- in the event that they aren't just the original parameter values. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:tc-dev- > [EMAIL PROTECTED] On Behalf Of Geert Bevin > Sent: Thursday, November 29, 2007 2:23 PM > To: [email protected] > Subject: Re: [tc-dev] class merging quandary > > How about changing the FooTC constructor into a synthetic method and > calling that at the end of the Foo constructor. This could still > create problems though when a method of Foo is overridden, is called > from Foo's constructor and relies on values from FooTC's constructor. > > -- > Geert Bevin > Terracotta - http://www.terracotta.org > Uwyn "Use what you need" - http://uwyn.com > RIFE Java application framework - http://rifers.org > Music and words - http://gbevin.com > > On 29 Nov 2007, at 23:05, "Tim Eck" <[EMAIL PROTECTED]> wrote: > > > We use a process called "class merging" to produce the terracotta > > enabled > > variants of things like HashMap, Hashtable, ConcurrentHashMap, etc. > > The > > basic idea is that we write a class called something like HashMapTC > > where > > we provide alternate implementations of methods, introduce new fields, > > etc. The merger thingy than takes HashMapTC and lays it overtop the > > original implementation of HashMap. I'm leaving out a bunch of > > details, > > but that is the general idea. > > > > One thing the merge process does not touch is constructors however, > > which > > has lead to at least one bug. Consider this code: > > > > class HashMapTC { > > private boolean flag = true; > > } > > > > Statements like that field set are duplicated into all constructors > > by the > > regular java compiler. Since our merge process does not use > > constructors > > from the "TC" class, the merged class just ends up getting the > > field, but > > not the assignment to true (instant bug!) > > > > I'm trying to figure out what the class merge should be doing here. I > > guess it stands to reason that we need to behave just like the java > > compiler does -- copy that statement into all constructors. That is > > probably easier said than done since the compiler conceals the > > structure > > of the source when it duplicates things. > > > > I'm mostly looking for thoughts about how the class merger can work > > better > > so that this type of bug can't happen again. > > > > thanks > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > tc-dev mailing list > > [email protected] > > http://lists.terracotta.org/mailman/listinfo/tc-dev > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
