-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
File references #9
Comments
At Insomniac we used the mcpp so we could
One benefit though is having all the power of a C pre-processor available for use in the DDL files. I was recently thinking in different ways to add references to other files in an in-house DDL, and thought about requiring fully qualified IDs for types defined in other files, but didn't have the time to explore it. It was something like this: struct particle {
math::vec3 position;
math::vec3 velocity;
};
|
I agree with the avoid Meanwhile I've been thinking a path include might not be needed at all. In the initial discussions a project system topic was debated, or lack of, where it will probably end up being the responsability of the pipeline to pass the tooling with a list of files to be included. Lets assume you have a
with your
And we could pass a list of namespaces to be included automatically to the libraries and tools, allowing us to use |
I dislike
The pipeline won't know which files a particular DDL file will need, and we don't want to pass all existing DDL files every time the tooling is invoked. My two favorite ways to deal with this:
The difference between Both options need all DDL files to exist under a common root folder, which I wanted to hate but don't. This root folder would be a parameter to the tooling. |
Do you have examples of those confusions? Always useful to know the shortcomings of other implementations. I think this discussion is starting to invade the scope of the project system, whatever that will be, so might be better to create a new issue for this :) (Issue #11) Regarding the convention approach I have to argue against it. This project aims to create both a file syntax and tooling to support its use. If we implement any convention that goes against the existing implementation of a project, that is one less project that can benefit from this, and by consequence less value this project brings to the community. But I like way |
Nothing special, just a developer that used
+1 |
I think I see the concern. I'm assuming the DDL tooling on that project somehow added the |
Sorry, I was under the impression that you were suggesting that DDL supported |
Ah, right. That too. Was mixing both functionalities, without even noticing it, were the two functionalities are:
Might not be a good idea to do a 2-in-1, but maybe we can. We could paraphrase Rust
For this file, the Then the type system maps any type prefixed with Seems simple enough to me, and hopefully sorts out your dislike for |
I'm used to read |
The keyword itself can be Important is to figure out the behavior. Is there a benefit of separating things with two statements like C++ does, or can we keep things simple and do the 2-in-1 above? |
Less magic is better. I would never thing about implementing something like C++'s |
There are a myriad of reasons to split type definitions across several files, which unfortunately raise the issue of how to point at the files containing the type definitions being used.
Please comment on possible solutions, past experiences, successes, and also very important, failures.
The text was updated successfully, but these errors were encountered: