|
| Re: Restricting Xbase in my own grammar [message #870040 is a reply to message #857051] |
Sat, 05 May 2012 22:34  |
 Jan Koehnlein
Messages: 760
Registered: July 2009
Location: Hamburg |
Senior Member |
|
|
1) The main bug is marked as resolved, and its follow up bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=378325 is marked as Juno
M7. So we will try our best to fix it for the Juno release. Patches are
welcome.
2) As long as you keep enough of Xbase, I'd say it's a good idea to
strip some "details" of Xbase. The decision whether this makes sense is
simply yours. I'd go the reverse way - copying the things you need from
Xbase - if I had the impression of dragging to much unused Xbase runtime
stuff behind me.
3) That depends on your usecase ;-) If you're brave, tweaking other
services like the scope provider could also be amenable in some scenarios.
Am 26.04.12 09:45, schrieb Kai Kreuzer:
> Hi,
>
> It is very nice and easy to extend Xbase in your own grammar. But as it
> is already quite powerful, I think the opposite thing is also
> interesting for many: Restricting some functionality, e.g. closure
> support or exception handling support - in order to make the expression
> language more "business user compatible".
>
> I have been trying to achieve this for a while, but I am blocked by this
> bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=347171
>
> So my questions are:
> 1. Is there still a chance that this bug is fixed for Juno?
> 2. Is "restricting Xbase" at all a valid and encouraged use case?
> 3. Is there any better way to achieve the goal than by overwriting rules
> defined in Xbase.xtext?
>
> I would be very grateful for any hints here!
>
> Thanks,
> Kai
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
---
Get professional support from the Xtext committers at www.typefox.io
|
|
|
Powered by
FUDForum. Page generated in 0.02980 seconds
] 
Search
Help
Register
Login
Home
