Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[Dltk-dev] Re: Extending the IInterpreterInstallType interface

Hi Gabriel,

I have increased visibility of getInterpreterType() to protected.

At the moment I don't see enough reasons to introduce new method, especially if it would be called from the single place.

If you like you can always introduce your own IMyType interface, let your InterpreterTypes implement it, provide different implementations and call it from your dialog class.

Hope it helps.

Regards,
Alex

----- Original Message -----
From: "Gabriel Petrovay" <gabipetrovay@xxxxxxxxx>
To: "dltk-dev" <dltk-dev@xxxxxxxxxxx>
Cc: alex@xxxxxxxxx
Sent: Thursday, April 23, 2009 6:46:35 PM GMT +06:00 Almaty, Novosibirsk
Subject: Extending the IInterpreterInstallType interface

Hi Alex,

Could you provide this abstract method:
String generateInterpreterName() in the IInterpreterInstallType
interface? This will be called from the
AbstractScriptInterpreterDialog.generateInterpreterName(). If the
result is null, the current implementation will take over.

A hack can be implemented in my extension of
AbstractScriptInterpreterDialog but only if you make the interpreter
install types combobox or an associated accesor method protected. This
is also the ugly version since I have to check in my code for the
particular install type and only for that to override the
functionality of
AbstractScriptInterpreterDialog.generateInterpreterName().

I hope you agree that the first option is a better choice. Please let
me know what you have against such a method: String
generateInterpreterName() in the IInterpreterInstallType interface.

Thanks!

Best regards,
Gabriel


-- 
MSc Gabriel Petrovay
MCSA, MCDBA, MCAD
Mobile: +41(0)787978034


Back to the top