search

coala / cEPs

coala Enhancement Proposals
MIT License
33 stars 53 forks source link

cEP-0033: Handle Nested Programming Languages #188

Closed Naveenaidu closed 3 years ago

Naveenaidu commented 5 years ago

Closes https://github.com/coala/cEPs/issues/187

Naveenaidu commented 5 years ago

@virresh @damngamerz @margobra8 Could you Please review the cEP ^^

Naveenaidu commented 5 years ago

I wanted to discuss the approach of creating the temporary files.

There is another way we could do this, where we do not have to create in memory coala sections for each nested language during run time. To do that, we actually create the physical files in the location. That means instead of having a variable such as temp_html_file store the contents of the nested language.

We can create a real file temp_html.html and temp_php.php and dump the contents into it. This would also overcome the problem of us explicitly creating a nl_file_dict and replacing file_dict with it.

The problem in doing so, as lot's of reviewers in my proposal suggested that would be a huge overtime in creating the temporary files and then deleting them after assembling.

But while reading the https://github.com/coala/cEPs/pull/180/files , I realized - if in future coala drops the support of normal .coafile and defaults to TOML configuration then the part of creating sections would have to be rewritten. I don't think that would be a much a problem, because even in the current implementation, we just break down the arguments and ask coala to make sections.

Need your opinions on the approach of creating physical files to store the segregated snippets of nested languages.

PrajwalM2212 commented 5 years ago

But while reading the https://github.com/coala/cEPs/pull/180/files , I realized - if in future coala drops the support of normal .coafile and defaults to TOML configuration then the part of creating sections would have to be rewritten. I don't think that would be a much a problem, because even in the current implementation, we just break down the arguments and ask coala to make sections.

Ultimately TOML configuration infrastructure generates coala sections. So even if in future coala drops the support of normal .coafile and defaults to TOML configuration, there would be no need to change the current implementation regarding your project because I am not changing the format of coala sections.

I think the part of creating sections regarding your project would have to be rewritten only when the current Section and Setting classes are changed or if .coafile syntax is changed. TOML configuration does neither of those.

PrajwalM2212 commented 5 years ago

Nice plan. 👌

Naveenaidu commented 5 years ago

But while reading the https://github.com/coala/cEPs/pull/180/files , I realized - if in future coala drops the support of normal .coafile and defaults to TOML configuration then the part of creating sections would have to be rewritten. I don't think that would be a much a problem, because even in the current implementation, we just break down the arguments and ask coala to make sections.

Ultimately TOML configuration infrastructure generates coala sections. So even if in future coala drops the support of normal .coafile and defaults to TOML configuration, there would be no need to change the current implementation regarding your project because I am not changing the format of coala sections.

I think the part of creating sections regarding your project would have to be rewritten only when the current Section and Setting classes are changed or if .coafile syntax is changed. TOML configuration does neither of those.

Niceeee! Thanks for clarifying. And thanks for the review too ^_^