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,
Andrey
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.
--
-jae
