In the CoffeeScript 1.9.0 ChangeLog, I read:
Changed strategy for the generation of internal compiler variable names. Note that this means that #example function parameters are no longer available as naked example variables within the function body.
I don't quite understand what this means for me as a user. Is this somehow an incompatible change? Can I safely upgrade to version 1.9.0?
It depends. Yes, this change is incompatible. If you had written tests, you could check if it affects you. Take this little piece of code:
example = "new"
obj = method: (#example) -> console.log(example)
obj.method "old"
In 1.8 this would print old. In the new version, this prints new.
In the older version, #example would be translated to example in the method parameters. So you're accessing obj.method's function parameter in the old version.
In the new version you're accessing the example variable of the outer scope. a.example still gets set to "old" in both cases.
Here you can see the difference in the generated JS code:
-// Generated by CoffeeScript 1.7.1
+// Generated by CoffeeScript 1.9.0
(function() {
var example, obj;
example = "new";
obj = {
- method: function(example) {
- this.example = example;
+ method: function(_at_example) {
+ this.example = _at_example;
return console.log(example);
}
};
obj.method("old");
}).call(this);
See Patrick J. S.’ answer for what the change means.
See How do I find cases of CoffeeScript 1.9.0 breaking change in my code? for how to know if you can upgrade safely, and what you need to do if not.
Related
Preemptive rtfm disclaimer: StructureMap's documentation is a major version out of date, and the API it documents doesn't even exist anymore, not to say anything for the attributes marked obsolete.
I have an environment setting, that for all intents and purposes can be treated as a static application-scoped boolean. The result of this boolean needs to control which implementation of my interface is plugged in. The sample documentation for conditionals is perfect for what I'm looking for, but none of those methods exist in 3.1.1.134 (latest in NuGet as of 9/8/2014).
I am looking for the current version of the following pseudo-syntax, and do not let "GetEnvironmentVariable" be a red herring -- it is just an example of a runtime system-wide boolean that needs to be evaluated on graph building.
public ConditionalInjectionRegistry : Registry
{
For<IBehavior>().UseConditionally(u =>
{
u.Conditionally(() => Environment.GetEnvironmentVariable("foo") == "bar")).Is<FooedBehavior>();
u.Default.Is<NormalBehavior>();
});
}
According to the mailing list, the correct way to do this now is with a lambda inside Use().
For<IIndexResolver>().Use("some description for diagnostics", c => {
// and just do it all with a single anonymous lambda
});
Where org.eclipse.xtext.xbase.validation.XtypeJavaValidator is supposed to be?
Xtext needs it in a generated file Abstract*DslJavaValidator. This type replaces org.eclipse.xtext.validation.AbstractDeclarativeValidator from Xtext 2.3.0 but I can't find this class anywhere in Xtext 2.4.1.
2.4 has XbaseJavaValidator but I'm not sure whether I should use this (the code being generated by Xtext and the access to this class being discouraged).
Are there instructions anywhere how to upgrade from 2.3 to 2.4?
By blindly messing the URL, I was able to generate a list of bugs with the title "Whiteboard: v2.4" but I'm not sure whether a) this is the actual list of bugs and b) how to get the list for 2.4.1.
The prefix of the class is generated from the base grammar. So if your grammar starts with
grammar ...
with org.eclipse.xtext.xbase.Xtype
the code generators will try to extend XtypeJavaValidtor. If you derive from Xbase, it will use XbaseJavaValidtor (i.e. name of grammar + JavaValidtor)
This bug report contains a workaround:
Workaround: pass inheritImplementation=false in the workflow like this:
fragment = validation.ValidatorFragment auto-inject {
inheritImplementation = false
}
Same is probably true for the ImportNamespacesScopingFragment, ContentAssistFragment and QuickfixProviderFragment
I am attempting to use LuaJ with Scala. Most things work (actually all things work if you do them correctly!) but the simple task of setting object values has become incredibly complicated thanks to Scala's setter implementation.
Scala:
class TestObject {
var x: Int = 0
}
Lua:
function myTestFunction(testObject)
testObject.x = 3
end
If I execute the script or line containing this Lua function and pass a coerced instance of TestObject to myTestFunction this causes an error in LuaJ. LuaJ is trying to direct-write the value, and Scala requires you to go through the implicitly-defined setter (with the horrible name x_=, which is not valid Lua so even attempting to call that as a function makes your Lua not parse).
As I said, there are workarounds for this, such as defining your own setter or using the #BeanProperty markup. They just make code that should be easy to write much more complicated:
Lua:
function myTestFunction(testObject)
testObject.setX(testObject, 3)
end
Does anybody know of a way to get luaj to implicitly call the setter for such assignments? Or where I might look in the luaj source code to perhaps implement such a thing?
Thanks!
I must admit that I'm not too familiar with LuaJ, but the first thing that comes to my mind regarding your issue is to wrap the objects within proxy tables to ease interaction with the API. Depending upon what sort of needs you have, this solution may or may not be the best, but it could be a good temporary fix.
local mt = {}
function mt:__index(k)
return self.o[k] -- Define how your getters work here.
end
function mt:__newindex(k, v)
return self.o[k .. '_='](v) -- "object.k_=(v)"
end
local function proxy(o)
return setmetatable({o = o}, mt)
end
-- ...
function myTestFunction(testObject)
testObject = proxy(testObject)
testObject.x = 3
end
I believe this may be the least invasive way to solve your problem. As for modifying LuaJ's source code to better suit your needs, I had a quick look through the documentation and source code and found this, this, and this. My best guess says that line 71 of JavaInstance.java is where you'll find what you need to change, if Scala requires a different way of setting values.
f.set(m_instance, CoerceLuaToJava.coerce(value, f.getType()));
Perhaps you should use the method syntax:
testObject:setX(3)
Note the colon ':' instead of the dot '.' which can be hard to distinguish in some editors.
This has the same effect as the function call:
testObject.setX(testObject, 3)
but is more readable.
It can also be used to call static methods on classes:
luajava.bindClass("java.net.InetAddress"):getLocalHost():getHostName()
The part to the left of the ':' is evaluated once, so a statement such as
x = abc[d+e+f]:foo()
will be evaluated as if it were
local tmp = abc[d+e+f]
x = tmp.foo(tmp)
Why doesn't eclipse show an error when I use a variable without declaring it?
Edit:
AFAIK dynamic nature only means that type of variable is not known until run time. The variables must still be defined (explicitly or implicitly) before being used. For example - Python which is also a dynamic language reports this as an error.
Edit2:
How does groovy interpret this code so that it still isn't an error?
Because in dynamic languages like groovy, one could have implemented methodMissing() / propertyMissing(). So although such variable or method does not actually exist, it may be still not be an errors until the program is actually run. Such errors can usually only be detected at runtime and hence IDE's usually don't complain about it.
Although to hint you, eclipse is underlining such variables there which it is not able to statically reference.
EDIT :
To explain the concept by code example, just check the method test below. Now IDE can't know that something , that ... can actually be a method in this class.
This vastly helps in building DSLs in groovy.
class TestClass {
def test() {
def a = something.that.didnt.exist()
or how about some random statements that make no sense at all
a = ew Parser().doSomething() ew blah blah blah
}
def propertyMissing(String name) { println "$name"; return this }
def methodMissing(String name, args) { println "$name with $args"; return this }
}
new TestClass().test()
I think you may try to use #CompileStatic tag on method.
Then Eclipse will compile and check errors at compile time or in develop time.
I haven't Eclipse to check this now, so this is just for a proposal.
I'm working on an xml project in Xquery (using Exist) and I was wondering how I could achieve the following:
I want to create a function evaluate:
evaluate(argument, function)
argument here can be anything and should be compatible with the function.
function is a reference to a function.
some examples:
evaluate(6,nextPrime) -> newtPrime(6) = 7
evaluate("text",toCaps) -> toCaps("text") = TEXT
Is this or something very similar possible in Xquery? And if so, how?
Thank you in advance!
I couldn't tell you about exist, but MarkLogic has function pointers:
xquery version "1.0-ml";
declare function local:upper($str)
{
fn:upper-case($str)
};
let $function := xdmp:function(xs:QName("local:upper"))
return xdmp:apply($function, "blah")
Evaluating this returns BLAH.
dave was right similar support for higher order functions is found in Exist.
http://en.wikibooks.org/wiki/XQuery/Higher_Order_Functions
I did not use the exist mechanisms since QName only supports string literals and I could not achieve the dynamic behaviour I needed for my application.
Instead I used this trick:
declare function moviestat:call1($name, $param){
let $query := concat($name, "($param)")
return util:eval($query)
};
note that a generic function for any number of arguments can also be made
(but was not needed in application)