From: Gergely K. <ger...@ma...> - 2010-03-21 14:10:46
|
Hi, I think the cause of the problem is the "3 phase" initialization of the Java objects. As you wrote in your mail, currently each object is initalized like this: x = [[[TypeName alloc] init] autorelease]; [x __init_TypeName__parameter_types: parameters]; // This is the actual Java constructor If we could change this convention to the following: x = [[[TypeName alloc] __init_TypeName__parameter_types: parameters] autorelease]; And then in the __init method, it would call the super constructor __init_SuperTypeName_*, while in the Java Runtime we could simply use: self = [self initWithClassSpecificParameters: parameters]; return self; This approach would have advantages in many places, like the UIWindow that you mention, or e.g. immutable classes, like NSString, NSURL ... etc., where we had to introduce hacks of various sorts, like a special constructor for NSString, a dynamic proxy for NSURL. What do you think? Best Regards, Gergely 2010/3/21 Panayotis Katsaloulis <pan...@pa...> > Hello again > > Today I experienced an issue, which produced some strange behavior and I am > thinking if there is any way to solve it. > This behavior actually appeared to me with UIWindow (which was easily > solvable) but I am thinking of a more generic solution. > > The problem is with objects that request a specific initialization to be > performed, other than [object init] > The auto-generated code of any object has something like > [[[NSObject alloc] init] autorelease] > which is fine, but it is wrong with objects like UITableView which > specifically request arguments in their initialization selector, which can > not be changed afterwards (like the "style" property). > > What is done right now is to call once the generic "init" selector, and at > later time call the more specific initWithFrame:style: selector. > Thus initializing the object twice! > > In this specific case there doesn't seem to do any harm, but I have found > out that in other cases, like UIWindow this might lead to serious problems! > Of course solving UIWindow was an easy task, just replace initWithFrame: > with setFrame: (since init was already called). > > I am wondering though: is there any way to call the specific initWithXXX: > function instead of the generic one? > Or, in other words, is it possible to avoid this double initialization of > the object? > > > PS: I am massively creating a patch to avoid if possible all non-needed > init selectors in the library, but this is just a convenient solution for > special cases, not a generic one. > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > -- Kis Gergely MattaKis Consulting Email: ger...@ma... Web: http://www.mattakis.com Phone: +36 70 408 1723 Fax: +36 27 998 622 |