Unable to importc objc class hierarchy #894

Closed
gradha opened this Issue Feb 9, 2014 · 2 comments

Comments

Projects
None yet
2 participants
@gradha
Contributor

gradha commented Feb 9, 2014

The importc pragma works ok for single objc classes, but can't be used to model hierarchies of external classes. The following code illustrates in valid Nimrod code what I want to do:

block:
  {.passL: "-lobjc".}
  {.passL: "-framework AppKit".}

type
  TNSObject* = object of TObject
  PNSObject* = ref TNSObject

  TNSString* = object of TNSObject
  PNSString* = ref TNSString

proc check_isa*(x: PNSObject) =
  echo "The isa value is ", repr(x)

when isMainModule:
  var a: PNSString
  check_isa(a)

Essentially, this models the objc NSObject with NSString being a subclass. Now, trying to do the same with importc:

type
  TNSObject* {.importc: "NSObject", inheritable,
    header: """<Foundation/Foundation.h>""".} = object
  PNSObject* = ptr TNSObject

  TNSString* {.importc: "NSString".} = object of TNSObject
  PNSString* = ptr TNSString

Nimrod compiles fine but fails during backend compilation:

/private/tmp/cycle/nimcache/cycle_h.m:109:27: error: 'NSString' does not have a
      member named 'Sup'
        checkisa_80015(&a_80026->Sup);
                        ~~~~~~~  ^
/private/tmp/cycle/nimcache/cycle_h.m:115:17: error: application of 'sizeof' to
      interface 'NSObject' is not supported on this architecture and platform
NTI80007.size = sizeof(NSObject);
                ^     ~~~~~~~~~~
2 errors generated.
Error: execution of an external program failed

As far as I can see in the generated code, the compiler is generating code for the imported classes as if they were normal nimrod structs, hence the access of the Sup field or trying to initialize the structure with sizeof.

How could this be avoided? It seems that the only way to make something like this work is teach the codegen part about objc classes. If on the Nimrod side they can't be expressed as object of XXX then the only other solution I can see is adding converters for all types to their base types or manual casting between them.

Maybe this has been already solved for C++ interfacing?

@gradha

This comment has been minimized.

Show comment
Hide comment
@gradha

gradha Feb 10, 2014

Contributor

Testing with c2nim suggested marking classes as pure but still the same C code was being generated.

Contributor

gradha commented Feb 10, 2014

Testing with c2nim suggested marking classes as pure but still the same C code was being generated.

@Varriount

This comment has been minimized.

Show comment
Hide comment
@Varriount

Varriount Jun 30, 2014

Contributor

Moved to nim-lang/c2nim#1

Contributor

Varriount commented Jun 30, 2014

Moved to nim-lang/c2nim#1

@Varriount Varriount closed this Jun 30, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment