[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dash-dev] Re: Translated samples into Groovy
|
I think we're saying the same thing - "write the core DOM that exposes a Java object and provide a language specific DOM that can wrap that core DOM's object in a manner convienient for that language environment"
I'm just saying that those are 2 extensions, not 1. that way, someone can write just the Java object if that is all that is needed, and other languages can leverage those unified core Java objects.
I think we are saying the same thing, so how about the org.eclipse.eclipsemonkey.dom extension point that has the java class implementation defined and then a new org.eclipse.eclipsemonkey.dom.lang extension point that is defined to wrap an already existing
org.eclipse.eclipsemonkey.dom extension point with a lang attribute. This would encourage people to write a DOM as a core DOM first and then wrap it for a particular language like _javascript_. This should make all DOMs universally accessible and allow for making objects that are more friendly for a particular language. What do you think?
By the way, you CAN use any Java object from within JS, and it will autowrap it, it's just not always doing it 'right' or in the way you'd like.
On Feb 13, 2007, at 9:49 AM, James Ervin wrote:
My concern with having a single DOM extension specify the language (versus having a core DOM extension and a language extension) is that it means most languages will have to start from scratch with regards to DOM support. That is, if you want to get to the editors in Python, then you probably have to write your own support for that versus using the core DOM facility for getting to editors.
I agree if you think that most DOMs are only going to be written with one language in mind. The DOMs that I include by default in Groovy Monkey are just Java objects and are not wrapped, those DOMs can be easily used in Groovy, Beanshell and I think even Ruby. I think that the best idea is what was proposed earlier, write the core DOM that exposes a Java object and provide a language specific DOM that can wrap that core DOM's object in a manner convienient for that language environment.
I still wonder if some of the wrapping being performed for _javascript_ could not be automated and provided for any DOM that is accessed by a Monkey script written in _javascript_? That would be ideal since all of the _javascript_ specific code could be isolated in one plugin/fragment and DOM code would never be coupled to a particular language implementation.
On Feb 13, 2007, at 9:23 AM, James Ervin wrote:
So those DOMs you provide are similar to the DOMs that i've worked on for JS. Given that, I think if we just agree on a set of 'core DOMs', we can have a language independent set, then we can each write any additional bindings that we may require specific to our language.
We can define two extension points, one for the generic DOMs (monkey.doms) and one, optionally, for specific language support (monkey.languages).
I wrote a lang extension point that simply brings the scripting engine to the table. I think perhaps defining an optional language attribute for the DOM would be better.
Of course, maybe the _javascript_ portion could automatically wrap and introspect for methods to make it more friendly for writing in _javascript_. Hmmm... maybe something more general or generic, so that it could be included in the language extension for _javascript_. I have throught of something similar for Groovy perhaps with the use of Categories.
The language extension point can also specify one or more required core DOMs -- if they aren't available or cannot be downloaded, then that lang extension wouldn't load.
Since in groovy monkey I implemented an outline view that shows what is included in that script's current binding, I would rather that if a DOM does not load, then it just doesn't show for that script.
This is the direction I'm working toward right now -- give me a few days and I can have this system in place for us to try out.
I think I might try adding the optional lang attribute to the DOM definition and try out your scripts in _javascript_ directly in Groovy Monkey (hey what can I say? I don't quite want to give up on my little tool... )
On Feb 13, 2007, at 8:00 AM, James Ervin wrote:
There is a default set of DOM(s) that get provided in Groovy Monkey for everyone. One of them is bound to window which maps to the IWorkbenchWindow class. I also provide a few more like monitor ( which allows you to update the status of the running script as well as provide for cancellation ), metadata which references the script's ScriptMetadata class ( useful for knowing the script name, script project, etc... ), runnerDOM which allows you to invoke another Monkey script in the workspace, workspace that maps to IWorkspace, etc...
I have an outline view in groovy monkey ( shown in the included jpg in this email ) that shows the mappings, plus content assist to autocomplete bound vars from DOMs and autocomplete methods defined in the DOM class ( and superclasses ).
James
This line, for example:
window.activePage.activeEditor
Where is this DOM defined?
--
James E. Ervin, IV
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.
-Robert A. Heinlein
--
James E. Ervin, IV
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.
-Robert A. Heinlein
