Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [Dltk-dev] debugger patches

Hello Jae,


First of all, we’re very excited about your contribution and you great help. As for debugger code, Dmitry is doing some refactoring there and I guess he is not finished yet (at least he was hurrying today committing code and merging branches). So, hopefully some of your changes are not in yet (or just not merged back…). Disappeared documentation is far from any guidelines. As for other things I hope Dmitry would comment shortly.


Thank you again, and

Kind Regards,



P.S. +1 to bring that docs back!



From: dltk-dev-bounces@xxxxxxxxxxx [mailto:dltk-dev-bounces@xxxxxxxxxxx] On Behalf Of Jae Gangemi
Sent: Friday, July 13, 2007 10:31 PM
To: DLTK Developer Discussions
Subject: [Dltk-dev] debugger patches


i just synced against the HEAD to pull down the commits that contained the patches that i submitted, and i am curious to know why some of the changes that i made did not make it. i'd like to try and improve the work submitted in the future, and also discuss why i may disagree with some of the reverts.

  - i wrote javadoc and left @see comments on methods that were overridden, etc. those have been removed. this one surprises me the most b/c i've seen people asking about documentation and i was trying to fill that gap when/where i could. (i find the @see comments useful b/c i know exactly what method is being overridden/implemented in the class hierarchy). it seems that some documentation is better then no documentation, so if there are guidelines on this, i'd like to know.

  - the calls to save the plugin preferences were moved to the AbstractScriptDebuggingEngineConfigurationBlock b/c that's what the IPreferenceConfigurationBlock interface states its performOk method is supposed to do, so i felt this change brought things more in line w/ the api - is this not the case?

  - methods were added to the InterpreterConfig class to encapsulate getting/setting the host, port, override_exe etc so that that classes that interact with those common properties did not need to know what keys were used to store them - they could just call set/get methods to adjust them accordingly. the manner currently being used breaks the idea of encapsulation and doesn't insulate the sub-classes from changes that may need to be made that could affect those common properties.

  - it looks like the work i did for the debugging path validator got moved around, but not the error messages (i tried to clean up the grammar a bit more, no offense meant by this).

  great work on everything overall, i'm glad i was able to make the contribution - hopefully they will be a real benefit to others.

Back to the top