Re: [Dltk-dev] Extending and increasing visibility for members of Abstra

[Alex Panchenko <alex@xxxxxxxxx>]

Hi Gabriel,

I think there is no need to duplicate every discussion in bugzilla. Bugzilla is more useful for bugs & long-term discussions, but I doubt this is the one.

Btw, the most extensible way for AddScriptInterpreterDialog it just extract interface from it, so languages could provide their own implementations.

Please for more comments inline.

Regards,
Alex

Gabriel Petrovay wrote:
> Hi,
> 
> The current version of the AbstractScriptInterpreterDialog class does
> not allow for extension (unless completely reimplemented). Plugins
> for
> many languages might want to have the following functionality:
> 
> 1. Allowing the automatic completion of (arguments/environment
> variables/name) based on the logic defined in the interpreter install
> type

I have added setInterpreterName(String) method you suggested earlier.
Please let us know if you need additional methods here.

> 2. The Interpreter install type should also have one method [boolean
> supportsEnvironmentVariables() ] in order to allow the enabling of
> environment variable block per install type. (This cannot be
> performed
> in the extended MyAbstractScriptInterpreterDialog class because this
> should not be aware of the install types)

Could you please give the detailed description why this method would be helpful?

> 3. As suggested in a previous email, the generation of the
> interpreter
> names should be overridable by the user in the
> InterpreterInstallType.
> The default implementation (suffixing with "(1)", "(2)",... ) should
> already be the default implementation of such generating method. In
> this way I could read a version number from somewhere and compose the
> name with the version in it, like JDT does it.

I made some refactoring in AddScriptInterpreterDialog:
- changed visibility of validateInterpreterLocation
- extracted generateInterpreterName & validateGeneratedName

> 4a. Also the interpreter arguments should be parametrized with
> variables. (DLTK should add some additional variables like:
> input_script_file, launch_config_args, etc). This is because not all
> the interpreters accept the format of the call:
>   script.exe [args] script.file
> others might need to put arguments after the script file, a.s.o.
> 4b. This is a more generic alternative to 4a. The Arguments field
> should be changed to Script Command Format. And allowing the full
> customization of the interpreter command line. An additional variable
> for this would be: interpreter_install_location.

The most generic way is to override org.eclipse.dltk.launching.AbstractInterpreterRunner.renderCommandLine(InterpreterConfig) method.

> 
> 
> Thanks!
> 
> Regards,
> Gabriel
> 
> -- 
> MSc Gabriel Petrovay
> MCSA, MCDBA, MCAD
> Mobile: +41(0)787978034
> _______________________________________________
> dltk-dev mailing list
> dltk-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dltk-dev