Covers from ooc classes don't work #437

Open
nddrylliog opened this Issue Jun 16, 2012 · 5 comments

Comments

Projects
None yet
2 participants
Member

nddrylliog commented Jun 16, 2012

Basically, their typedef is written before the #include of -fwd headers of other classes, which means the structs are not defined yet.

We should distinguish between covers of basic types, and covers of ooc classes. Covers of ooc classes should have their typedef written after the includes.

That'd allow cool stuff, for example in endorse, we want to do

Hash: cover from HashMap<String, String>

for much more convenient function prototypes and stuff.

Collaborator

shamanas commented Nov 19, 2012

https://gist.github.com/4111693
This confuses me greatly.
Pointer, CString and FStream, are the only three covers from ooc types in the sdk (although in the case of FStream I wonder why... it is defined as FILE: extern cover; FStream: cover from FILE* { ... })

I don't really know what the problem is because of how tangled the includes are in the rock generated headers, cannot quite twist my mind around it.

Member

nddrylliog commented Nov 19, 2012

@shamanas Haven't had time yet to understand everything's that going on in this gist, but in any case you should try clang/llvm for much better error message.

Collaborator

shamanas commented Nov 20, 2012

Bah, same thing, clang just gives "did you mean?" messages.
I think I know what happens though.
The typedefs are written after the imports, so for example IO.ooc auto-imports String.ooc, which needs FStream to compile but the FStream typedef is written after the String declarations.

This is another example:

A.ooc:

import B
B: cover from A {}

B.ooc:

import A
A: class {}
foo: B

(Note: the code generated here only yields an error if trying to compile A... Compiling B does not)

Collaborator

shamanas commented Nov 20, 2012

Actually, here is an even more general piece of code with the same behavior (when compiling A.ooc):

A.ooc:

import B
OocClass: class {}
Foo: cover from OocClass

B.ooc:

import A
foo: Foo
Collaborator

shamanas commented Nov 21, 2012

Not quite sure what I can do to fix this with the current state of rock.
I think our greater chance for a fix would be with the new code generation which will be implemented in rock 1.x, where you mentioned you wanted to have all the dependencies for a given module be written in its header file (structure definitions, typedefs, etc...)

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