<div dir="auto">Cool! Probably it wasn't clear my suggestion, but <span style="font-family:sans-serif">that's exactly what I meant: keep "scripts" but get rid of the special syntax and implement QgsProcessingAlgorithm subclasses.</span><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">Giovanni<br></font><div dir="auto"><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">Il 1 feb 2018 06:26, "Nyall Dawson" <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> ha scritto:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 31 January 2018 at 18:24, G. Allegri <<a href="mailto:giohappy@gmail.com">giohappy@gmail.com</a>> wrote:<br>
> I understand your point Victor, and I agree that scripts was a clever idea.<br>
> But:<br>
><br>
>  - with the current shape of Processing (QGIS 3.0) I think the "syntactic<br>
> sugar" provided by scripts has less relevance. As I can see from the<br>
> refactoring, there's less automation in parameters conversions and<br>
> management, and a few new "magic" context variables have been introduced. I<br>
> think scripts now are too similar to plain geoalgorithms, and consequently<br>
> the differences can become misleading and not easily understood.<br>
><br>
>  - syntactic sugar requires maintanance: if a new parameter is introduced, i<br>
> parameters are added or changed, the corresponding translation method for<br>
> scripts must be updated.<br>
><br>
>  - syntactic sugar requires doc maintanance, while Processing APIs<br>
> documentation can be mostly automated.<br>
><br>
> Anyway, this is a proposal to be discussed. Meanwhile I will try to estimate<br>
> the work needed to drop (and adapt) the current implementations.<br>
><br>
> PS: @Victor, it's nice to follow Processing's history! C++ (SAGA) -> Java<br>
> (Sextante) -> Python (Processing) -> C++ (QGIS 3.0)  :D<br>
<br>
I'm a bit late to this discussion, but my 2c:<br>
<br>
- I actually like the idea of single file script algorithms, and don't<br>
want to see them go. I can see lots of valid use cases for why they<br>
are needed. (In particular - I'd love to extend models in future to<br>
allow embedded script algorithms which are contained just within a<br>
single model, and not exposed elsewhere).<br>
<br>
- It's just the syntax of scripts which I'm not a fan of (for reasons<br>
well covered above)<br>
<br>
Alex has a WIP PR already at <a href="https://github.com/qgis/QGIS/pull/6225" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>pull/6225</a>  -<br>
stakeholder comments would be welcome here!<br>
<br>
Nyall<br>
</blockquote></div></div>