xmlvm-users

[xmlvm-users] "init" question

[Panayotis K. <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. 

Re: [xmlvm-users] "init" question

[Gergely K. <ger...@ma...>]

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&#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
>



-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622

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