Re: [xmlvm-dev] NSObject as superclass of CGImage/CGContext...

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

there are no value types in Java, so the only viable choice for 
representing an Objective-C value type is a class in Java. If value 
types are derived from each other, it makes perfect sense to do the same 
on the Java side. The wrapper for CFTypeRef should have something like a 
wrappedValueType similar to the wrappedObjCObj in NSObject. So, what you 
are proposing makes perfect sense and is the way to go!

Arno


On 9/11/11 12:38 PM, Markus Heberling wrote:
> I have removed the "extends NSObject" for the CG* stuff in this patch: http://xmlvm-reviews.appspot.com/155001/
>
> The patch is not yet complete, but I'd like to have some feedback if that is the right direction before I continue.
>
> In CoreFoundation there exists a CFTypeRef type, which is something like the super type of all the CGImageRef,CGContextRef... stuff
>
> Would it make sense to create a new CFType java class, and have the CGImage... classes extend that? That would make the wrapping code easier, since the storage of the wrapped C-Reference could all be done in the CFType wrapping code. Additionally there are the C functions CFRelease and CFRetain which you can use with any XXXRef type instead of the more specific CGImageRelease, CGContextRelease functions. Currently it would be very hard to implement the generic functions, since all CGXXX classes store the wrapped C reference in different members.
>
> Does that make sense, or am I talking gibberish here? :D
>
> Markus
>
> Am 01.09.2011 um 19:00 schrieb Arno Puder:
>
>>
>> a few comments:
>>
>> - Objective-C has the notion of value types, Java does not. A
>>    value type in Objective-C can only be mapped to a class in
>>    Java (e.g., CGRect, CGImage, etc).
>> - We try to mimic the class hierarchy as much as possible, hence
>>    the existence of class NSObject that serves as the base class
>>    of all Objective-C classes.
>> - Value types are not classes and therefore do not have a base
>>    class. Since they are mapped to classes on the Java side,
>>    they still have java.lang.Object as the base class in Java.
>>
>> I agree with Markus that value types should not be derived from NSObject
>> on the Java side. That should be fixed.
>>
>> Arno
>>
>>
>> On 9/1/11 5:28 AM, Panayotis Katsaloulis wrote:
>>>
>>> On 1 Σεπ 2011, at 1:48 μ.μ., Markus Heberling wrote:
>>>
>>>> Hi,
>>>>
>>>> Currently NSObject is the superclass of CGImage/CGContext/CG... and the like in the Java Compatibility Layer. In the "real world" this is not the case. CG... are no ObjectiveC objects altogether.
>>>
>>> You are right - this is my fault.
>>>
>>> First, in the Java context:
>>> CG* should not be NSObject derivative. It is still an Object derivative though.
>>>
>>> In native context:
>>> CG* *is* an Object since it is re-implemented here and is a wrapper for native CG* references.
>>>
>>>> Wouldn't it be better to remove the NSObject from the class hierarchy in java, too?
>>>
>>> In C you mean?
>>>
>>> NSObject in Java context *is* an Object, and as such, shouldn't NSObject and Object stay synonyms?
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Special Offer -- Download ArcSight Logger for FREE!
>>> Finally, a world-class log management solution at an even better
>>> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
>>> download Logger. Secure your free ArcSight Logger TODAY!
>>> http://p.sf.net/sfu/arcsisghtdev2dev
>>> _______________________________________________
>>> Xmlvm-developers mailing list
>>> Xml...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>>
>> ------------------------------------------------------------------------------
>> Special Offer -- Download ArcSight Logger for FREE!
>> Finally, a world-class log management solution at an even better
>> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
>> download Logger. Secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsisghtdev2dev
>> _______________________________________________
>> Xmlvm-developers mailing list
>> Xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>