[MonoDevelop] RefactoringCommands: Encapsulate Fields initial implementation

Miguel Ángel Pérez mangelp at gmail.com
Thu Apr 26 03:56:25 EDT 2007


My first implementation it's so simple that his usefulness is very limited,
but I'm going to implement your ideas to improve it ;)

Thanks for the comments!

2007/4/24, Ben Motmans <ben.motmans at gmail.com>:
>
> On 4/24/07, Miguel Ángel Pérez <mangelp at gmail.com> wrote:
> > ...
>
> Imho, there are several issues with this solution
> * the BuildEncapNameForField doesn't take '_' or 'm_' prefixes into
> account, plus this should probably be a language specific
> implementation or allow some user preferences. (eg: allow to strip
> prefixes from Hungarian notations)
>
> * encapsulate field should be non-invasive for the entire solution,
> not only the current class, so ExistsMemberWithName should not only
> check the current class, but also the base class or any derived
> classes, this should also check names of events
>
> * I don't think creating a new thread for every "encapsulate fields"
> command is the way to go, since this is a lot of overhead for a short
> running method, you should probably use
> DispatchService.BackgroundDispatch or ThreadPool.QueueWorkerItem
>
> * there should be more options when generating a property: allow to
> only create a getter or a setter and allow to override properties, for
> example: when the property
> public string Test { get { ... } } exists, and we encapsulate the
> field "test" with get+set, it should update this property instead of
> creating a property called Test1 (or at least ask the user what he/she
> wants to do)
>
> my 2 cents (though for an "official" answer, you should probably wait
> until Lluis or Jeff replies)
> -- Ben
>


-- Regards --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-list/attachments/20070426/e2680833/attachment.html 


More information about the Monodevelop-list mailing list