Re: [Dltk-dev] // XXX: what if multiple extensions define a selector

[Jae Gangemi <jgangemi@xxxxxxxxx>]

  my perl project does - i created an implementation that can use PPI to parse the document, but it requires the user to have PPI installed on their system, so i offer the option of a 'null' parser that just does nothing. 

  if i can ever get a good enough grasp of how antlr works, it'd be possible to create a parser based upon that.

  personally, i think it's better to have the flexibility to add multiple implementations from the get go. i had thought that most of the selectors were defined in the core w/o any available implementations, leaving the individual extension point to add it's own option but i haven't looked at that code in a long while so that thought may be incorrect.

On Wed, Feb 3, 2010 at 1:29 PM, Gabriel Petrovay <gabipetrovay@xxxxxxxxx> wrote:

Do you know projects that use multiple parsers in this way? If no, I
would eliminate the selector until it is requested by users. The
IProject in the patch from me that you committed today is used only
for the logic of the selectors.

But again, I would leave it without selector just like
sourceElementParsers. There is no selector there. Probably (I didn't
check), only the priority plays a role there.

I see that it is not an easy part to reason about. It also gave me
some headaches.


Gabriel

On Wed, Feb 3, 2010 at 4:54 PM, Alex Panchenko <alex@xxxxxxxxx> wrote:
> The problem is that at the moment selector is contributed by the same
> extension point.
> So, theoretically, a few selectors could be contributed. And it becomes
> unclear which selector would be called.
> Another way to solve the issue: not to contribute selector by the extension
> point, and hard code it in java, in the appropriate xxxExtensionManager
> class.
> ----- Original Message -----
> From: "Jae Gangemi" <jgangemi@xxxxxxxxx>
> To: "DLTK Developer Discussions" <dltk-dev@xxxxxxxxxxx>
> Sent: Wednesday, February 3, 2010 9:47:00 PM GMT +06:00 Almaty, Novosibirsk
> Subject: Re: [Dltk-dev] // XXX: what if multiple extensions define a
> selector
>
>
>   i realize i've been out of the game for a while, but if memory serves, the
> selector is what allows for the drop down list to occur and extensions are
> supposed to provide an implementation of the drop down item.
>
>  isn't this something that could just happen in general, where any extension
> could define an implementation and over write something that already exists
> in the 'core'? it seems this should be one of those 'design by contract'
> things, which means just don't do it. :)
>
> On Wed, Feb 3, 2010 at 10:33 AM, Alex Panchenko <alex@xxxxxxxxx> wrote:
>>
>> Hi Gabriel,
>>
>> I remember that discussion, but I am not sure what is the best choice
>> here.
>> I can suggest logging extra selectors to the error log.
>> What do you think? Do you have any other ideas?
>>
>> Regards,
>> Alex
>>
>> ----- Original Message -----
>> From: "Gabriel Petrovay" <gabipetrovay@xxxxxxxxx>
>> To: "dltk-dev" <dltk-dev@xxxxxxxxxxx>
>> Sent: Wednesday, February 3, 2010 9:13:37 PM GMT +06:00 Almaty,
>> Novosibirsk
>> Subject: Re: Re: [Dltk-dev] // XXX: what if multiple extensions define a
>>  selector
>>
>> Hi,
>>
>> There was this unanswered post:
>> http://dev.eclipse.org/mhonarc/lists/dltk-dev/msg01792.html
>>
>> Are there any plans in this direction?
>>
>>
>> Thanks!
>>
>> Gabriel
>>
>>
>>
>> --
>> MSc Gabriel Petrovay
>> Mobile: +41(0)787978034
>> www.28msec.com
>> _______________________________________________
>> 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
>
> _______________________________________________ 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
>
>

--

MSc Gabriel Petrovay
Mobile: +41(0)787978034
www.28msec.com
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev

-- 
-jae