Closed dsawardekar closed 11 years ago
Thanks for the ticket. I'll take a look on Saturday, but this should be a quick fix.
@luke-gru Can you clarify the approach you will be taking to fix this bug?
Would it be possible to implement some form of a DAG to let the compiler figure out the right order of the includes?
Currently the compiler checks for presence of classnames, so the order of the include is crucial, else you get ClassNotFound
errors. Not needing to worry about include order is handy.
I guess what I'm asking is for require to work more like import
. :smile:
Well, I already have the easy solution to this implemented in a branch, and it fixes this issue. It just keeps track of the filenames that were already included and only includes new filenames. The dependency resolver would be a bit more work, but it shouldn't be too bad. I'll experiment a bit with it and report back.
I think riml
also needs a way to either import classes or ignore undefined classes altogether, because if I'm making a library mylib
that has as a dependency some other library written in riml
, I should be able to use those classes in my library without having to compile or link with the other library during each compile of 'mylib'.
What are your thoughts on this?
The simpler solution sounds good for now.
Regarding dependency between libraries, A solution I've seen work to an extent is separate definition files. Eg:- Typescript has a Type Definition File that can be used to define the interfaces of a 3rd party library, so that it is able to compile against that library correctly. If my project used say jQuery, without a definition file a method call like $.foo
would be fine, whereas with the definition file it would throw a compile time error, like foo not found on $
.
Having said that this isn't an ideal solution, definition files tend to go out of sync as new revisions of the target library are released.
Hey @dsawardekar, yeah definition files are probably useful for statically typed languages that need to be compiled separately from the dependent libraries, but for Riml I think a good enough solution for now is to maybe have something like
riml_import g:ThirdPartyClass
to register the class with Riml, and then you can use it elsewhere without any errors.
Also, for the lazy, I'll offer a command-line option to turn off compile-time class checking, I think.
I'll open an issue for this, and gather thoughts there.
As for this ticket, I'm going to close it, as the fix for the original issue is in master. I'll add another ticket for the DAG class registration implementation.
This code is a little more involved. It's part of a plugin I'm working on. Consider a class
TemplateContext
with the code.I am including this class in another file. Which includes another and so on. I've narrowed down the issue is to do with duplicate include like below.
With such a duplicate
riml_include
the compiler get's very confused. See the output below. Further this outputviml
does not run, giving aendfunction missing
error.The compiler appears to be stuck inside an internal loop. The output is concatenated in places, blocks are misaligned, etc.
I think the easiest way to deal with this is to not output anything for the second
riml_include
.Or if you are going to include the second time then memoize/cache the result of a
riml_include
. So any secondary includes use the cached output instead.