make this happen --> HL.import("header/file.h", true)

[Sophrinix]

make it so!

just to be clear:
HL.import("header/file.h", true)
argument 0 is the header file in question
argument 1 is if this a systemframework aka #import<blah/blah.h>

also we need to talk about framework including

[davemackintosh]

What would this expose to the calling scope? Is this runtime or compile time? If it's compile time could we make it a pragma and not something in the runtime?

[mattapperson]

We are open to syntax suggestions that leave it as easily understood and documented. As well as it being valid JS

[davemackintosh]

Okay, few questions:

1.Is this a runtime thing?
Does it expose header contents to the calling scope? What headers would it support? C, Cpp, ObjC, C# etc? What about macros, pragmas, #defines?
If it's compile time I would suggest a less invasive syntax in form of a pragma type mark like Go, C, Cpp. In Go you would include a C header with // #import "my-header.h"
2. What does the boolean do? Surely import paths are project level, not file level?
3. What is the value of having this in the JS at all if at the end of the day everything runs through the compiler/linker anyway?

[TheBrousse]

Do we really need the second parameter? Can't it be determined at compile time?

[mattapperson]

No, sadly we can't. (Or at least if we can I am not smart enough to figure out how lol)

[mattapperson]

@davemackintosh

1. its a compile time thing. Currently this is being done as a CLI arg, but then you have to remember what is getting used.
2. the bool is about project headers vs framework headers
3. To define the headers used in a way that keeps things organized, that is valid JS. We tossed around the idea of comment based system like what JSHint uses for settings. The argument though was that this could be invalidated and the imports themselves could not be linted without a special parser. This being more like require would just "fit" better. And although not truly runtime, would look and feel as though it was thus easier to use/explain.

On all of this though, as always, things are open to discussion.

[davemackintosh]

Doesn't Hyperloop already have the @import function for grabbing native headers/frameworks? has anyone seen this @import('framework') working?

I can also see framework inclusion in the Hyperloop compiler? Lines 70, 191, 227
https://github.com/TiForward/hyperloop-common/blob/master/lib/compiler/clangparser.js

Looks like the place we need to look is at https://github.com/appcelerator/hyperloop-common/blob/master/lib/compiler/codegen.js#L291

[mattapperson]

@davemackintosh it used to have @import, but it was removed in favor of CLI based header includes. And yes it already has framework inclusion, but again, CLI based.

The issue there is, you have to run the CLI tool passing in headers and frameworks as args to the CLI. That just seems messy and error prone. Use cases exist for wanting to do that, sure. But a file based solution in the JS seems to make the most sense at least to me

[davemackintosh]

So it seems that they removed the framework inclusion in file for a project level framework inclusion. Not being funny but that seems sensible to me. I'm going to crawl the commit history to see when they removed it and what they actually changed then to see if we can restore something similar/the same.

[mattapperson]

@davemackintosh again, it makes sense for some things, but not all. This ticket is not for REMOVING the CLI based system, but just also providing another way.

[davemackintosh]

In this instance, I can see one of the reasons they moved away from the @import path, https://github.com/appcelerator/hyperloop/blob/master/examples/ios/opengl/js/app.hjs

So maybe there is a case to create an @import([..., ...])

[mattapperson]

In native Objc, there is an option to import, for instance Foundation in a parent file, normally main.m and then you dont need to import it again. The same should be able to be done here.

[mattapperson]

@davemackintosh one of the main reasons for getting rid of the @import syntax was a move from needing *.hjs files to js... making it valid JS