Re: [xmlvm-users] "init" question

[Arno P. <ar...@pu...>]

this is a very tricky issue. As Gergely pointed out, a JVM creates a new 
object in two steps: first allocate memory for the new instance (via 
instruction <dex:new>) and then call its constructor (via instruction 
<dex:invoke-special>). It is exactly this two step procedure that is 
difficult to map to Objective-C.

In Objective-C things are not that different. You first send a class the 
alloc message followed by an init* message. At some point I tried to use 
this fact by calling alloc for <dex:new> and init* for 
<dex:invoke-special>. However, for some strange reason Obejctive-C is 
very peculiar about calling alloc and init. If it is not done in a 
nested way via [[Class alloc] init], bad things happen.

I should also mention that it is not always guaranteed that <dex:new> is 
immediately followed by <dex:invoke-special>, otherwise one might do 
some peephole optimization.

I also noted the problem that Panayotis has come across, but I couldn't 
find an easy solution. If someone has a bright idea, I'm all ears!

Arno


On 3/21/10 6:09 AM, Gergely Kis wrote:
> 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...
> <mailto: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&#174; 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...
>     <mailto:xml...@li...>
>     https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
>
> --
> Kis Gergely
> MattaKis Consulting
> Email: ger...@ma... <mailto:ger...@ma...>
> Web: http://www.mattakis.com
> Phone: +36 70 408 1723
> Fax: +36 27 998 622
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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