Kewl :-) On 29 Nov 2007, at 23:53, Tim Eck wrote:
> I think I get what you're saying and it sounds pretty good to me. > Seems > you can't get it wrong and doesn't impose constraints that won't > work for > the current usage of the class merger. > > I think I'll try this out for now. Thanks! > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:tc-dev- >> [EMAIL PROTECTED] On Behalf Of Geert Bevin >> Sent: Thursday, November 29, 2007 2:43 PM >> To: [email protected] >> Subject: Re: [tc-dev] class merging quandary >> >>> 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 :-) >> >> I think that's taking it a step too far. Imho we shouldn't support >> non >> default constructors. In the examples that you've given it's clear >> that it's needed for handling the initialization of member variables. >> I don't think it's a good idea to actually advocate using the >> constructors of FooTC to do anything useful. It might even be good to >> catch all non default constructors and thrown an exception at >> instrumentation time. >> >>> 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. >> >> If the synthetic method is called at the end of Foo's constructor, >> the >> super calls can just be removed and it would function as expected, >> no? >> >>>> -----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 >> >> -- >> 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 >> >> _______________________________________________ >> 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 -- 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 _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
