Re: [Dltk-dev] Re: multiple source parsers

["Jae Gangemi" <jgangemi@xxxxxxxxx>]

  most of the logic in the manager classes came from code i pulled from the debugging engine manager - i hadn't yet pulled over the code for the selector implementation (that is in my latest round of changes), but it looks like the Comparator implementation is more robust then the current implementation, so i'll move that over to the priority selector implementation.

  i'm already working on the preferences interface as well - most of this work leverages various pieces of code for the debugging engines, although it looks like the solution to create new parsers will have to be carried a bit further b/c i'll need to know other pieces of information that the source parser configuration provides. this better explains why DebuggingEngineManager creates the DebuggingEngine instance and stores the factory inside it - i will probably try and move to an implementation that works in the same manor. i plan to create an 'id' based selector that will take care of storing the user selected parser and will work like the one for the debugging engine (noticing a theme yet?).

  as for the project specific parsers, if there was only one parser, then it wouldn't matter, but i feel that if we're going to allow multiple parsers for the overall workspace, we might as well allow specific parsers for individual projects. the individual projects would have to expose the property page themselves if they actually wanted users to select between them. i do want to allow for project specific debugging engines, so this functionality would become anyway available since the management of these contributions is handled by a lot of the same code.
  
  i finished up the first cut of the preference page last night, so if all goes well, these changes should land soon. 

  oh - i did see a lot of classes that grab the source parser when they are constructed and hold on to it as a member variable. this will have to be changed to ask for the parser each time it's needed once the individual language decides they want to allow the user to choose the parser.

On Dec 3, 2007 12:29 AM, Andrei Sobolev <andrei.sobolev@xxxxxxxxx> wrote:

Hi Jae,

I think that configurable source parser idea is good, but I want to
propose some corrections.

1) Sometimes we need to override some contribution implementation with
same name with new version, as new plugin.
(Priorities was made for this purpose). I've added some logic to
SourceParserManager and DLTKContributionExtensionManager to support them
if only one parer with specified name are contributed.

2) We need to store store selected contribution information in core
preferences and provide generic user interface to select contribution
for specified nature.

3) As for per project parser configuration, I think that it is not good
idea, because not for all languages multiple parsers will be available.

Also: Before your modifications, for each module we create parser instance.
This is essential logic, becase almost all our parsers are not thread safe.
I've modified DLTKContributionExtensionManager to hold
ContributionElement inner class, instead of executable object instances.

Best regards,
Andrei.

>  almost forgot, there is now an AbstractSourceParser base class that all
> ISourceParser implementations should inherit from that takes care of the
> 'informational' method implementations.
>
> On Nov 30, 2007 4:01 PM, Jae Gangemi < jgangemi@xxxxxxxxx> wrote:
>
>
>> hello all -
>>
>>   i've just committed the initial changes required to start allowing
>> multiple source parser extension point implementations (a unit test too!).
>> aside from a package change for ISourceParser and the schema changes, all
>> other underlying functionality remains the same.
>>
>>   if anyone out there is working against the HEAD in cvs, you will need to
>> update your sourceParser extension point to look something like this:
>>
>>    <extension point="org.eclipse.dltk.core.sourceParsers ">
>>       <parserContribution natureId=" org.eclipse.dltk.tcl.core.nature">
>>          <parser
>>                class="org.eclipse.dltk.tcl.internal.parser.TclSourceParser
>> "
>>                description="Tcl Source Parser"
>>                id="org.eclipse.dltk.tcl.sourceParser"
>>                name="Tcl Source Parser"
>>                priority="0" />
>>       </parserContribution>
>>    </extension>
>>
>>   the next steps will be to build a preference page that allows you to
>> choose the parser, and then to update calls that retrieve the parser to
>> determine which one to use based upon the user's preferences. once that's
>> done, my plan is to allow for project specific parsers and use that as a
>> basis to start adding some other project specific options (specifically
>> selecting which interpreter to use and allowing for project specific
>> debugging preferences [ie: break on first line, etc]).
>>
>> --
>> -jae
>>
>
>
>
>
>

> ------------------------------------------------------------------------
>
> _______________________________________________
> dltk-dev mailing list
> dltk-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>

_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev

-- 
-jae