According to MDN getComputedStyle(element) returns CSSStyleDeclaration object. But Flow tells that return type of method is any. Can I fix this without writing own type declaration?
It doesn't look like there is any particular reason, just that it hasn't yet been given a better type. You can see in the DOM libdef file that it is declared as returning any, and that line hasn't been touched in over four years.
This would be an easy first PR, if you are interested in improving it.
Related
Learning gremlin and looking at examples I see the use of as inside of where steps to match against a previously labeled step.
For example, from official recipes page, a vertex is labeled 'v' with as, later on inside a coalesce it looks for an inE where the outV equals to 'v', but it does so using as again:
gremlin> g.V().has('person','name','vadas').as('v').
V().has('software','name','ripple').
coalesce(__.inE('created').where(outV().as('v')),
addE('created').from('v').property('weight',0.5))
If I were to just read the reference documentation this query would look to me like they are just labeling that outV step as 'v' and nothing more.
This functionality of as doesn't seem to be documented in the reference documentation, and only shows in the examples with no special mention of it.
Does the previous query achieve the same as the following?
gremlin> g.V().has('person','name','vadas').as('v').
V().has('software','name','ripple').
coalesce(__.inE('created').where(outV().where(eq('v'))),
addE('created').from('v').property('weight',0.5))
Is this just a lack of documentation, or is there something I'm missing?
Is saying as has a special meaning inside 'where', correct? Or is there something else to take into account?
Yes - as() has special meaning inside where(). It is described briefly as part of the select()/where() usage (see item 3) and in the match()/where() usage. Basically when you write your query that way you are using where() with its variable binding form and is equivalent to the more direct form that you demonstrate in your second query. Personally, I tend to find the binding form a bit less readable, but that depends on the nature of the filter I guess and sometimes it represents the most clear way to structure the query.
As you observed, an as step is treated differently inside a where step to allow a step label created outside the where step to be treated as a label inside the where step and not a literal string.
There is a writeup here
http://www.kelvinlawrence.net/book/PracticalGremlin.html#patternwhere
As the documentation said
Do not store Contexts inside a struct type; instead, pass a Context explicitly to each function that needs it. The Context should be the first parameter, typically named ctx
but I found, in the typical http request handle function, a http.Request object has .Context() method can retrieve the context which http request associate with.
So why recommend to use context as the first parameter in these functions? Is that reasonable in this situation?
I know that is not an absolute rule. But I want to know why the HandlerFunc is func(ResponseWriter, *Request) instead of func(context.Context, ResponseWriter, *Request).
Apparently HandlerFunc breaks this recommendation.
As described in the documentation you quoted above, ctx should be a (very) common argument for many functions. This is similar to the way many functions return an error. The best place for a common argument/return value is either as the first, or last in a list. (Arguably, Go could have chosen to make error always be the first return value--I won't discuss that here).
Since variadic variables may only be the last in the list of function arguments, this leaves the only option for a common argument to be the first one.
I expect this is why ctx is always first.
This pattern is often seen with other variables in Go (and other languages) as well. Any time a common variable is used by a set of related functions, that common variable often comes first in the argument list (or possibly second, after ctx).
Contrary to the advice you quoted, there are libraries that store ctx in a struct, rather than passing it around as the first argument. These are usually (always?) libraries which had to be retro-fitted to use ctx, long after the library contract was set in stone (by the Go 1.x compatibility guarantee).
Generally, you should follow the advice to pass ctx as the first argument, for any new work.
This question slightly differs from check for variable number of sibling nodes & different siblings in Rapidxml. In most of the examples I have found on the web I see hard coded keys, for example:
xml_node<>* root = doc.first_node("rootnode");
Here "rootnode" is hard coded. My situation is slightly different, in the sense that parsing and tagging is already done by rapidxml. I need to know the names as read by the parser by iterating over nodes and their sibling without knowing the hard coded name and the depth of the node. I am looking for the suggestion/solution on some kind of recursive navigation along rapidxml tree.
Thank you.
According to RapidXml's documentation (see here) the node name parameter in first_node() method is optional. You can just omit that parameter and you will get the first child node, regardless of its name:
xml_node<>* root = doc.first_node();
Then you can just get node's name by calling its name() method.
How can I tell the Closure Compiler not to rename an inner function? E.g., given this code:
function aMeaninglessName() {
function someMeaningfulName() {
}
return someMeaningfulName;
}
...I'm fine with Closure renaming the outer function (I actively want it to, to save space), but I want the function name someMeaningfulName left alone (so that the name shown in call stacks for it is "someMeaningfulName", not "a" or whatever). This despite the fact that the code calling it will be doing so via the reference returned by the factory function, not by the name in the code. E.g., this is purely for debugging support.
Note that I want the function to have that actual name, not be anonymous and assigned to some property using that name, so for instance this is not a duplicate of this other question.
This somewhat obscure use case doesn't seem to be covered by either the externs or exports functionality. (I was kind of hoping there'd be some annotation I could throw at it.) But I'm no Closure Compiler guru, I'm hoping some of you are. Naturally, if there's just no way to do that, that's an acceptable answer.
(The use case is a library that creates functions in response to calls into it. I want to provide a version of the library that's been pre-compressed by Closure with SIMPLE_OPTIMIZATIONS, but if someone is using that copy of the library with their own uncompressed code and single-stepping into the function in a debugger [or other similar operations], I want them to see the meaningful name. I could get around it with eval, or manually edit the compressed result [in fact, the context is sufficiently unique I could throw a sed script at it], but that's awkward and frankly takes us into "not worth bothering" territory, hence looking for a simple, low-maintenance way.)
There is no simple way to do this. You would have to create a custom subclass of the CodingConvention class to indicate that your methods are "local" externs (support for this was added to handle the Prototype library). It is possible that InlineVariables, InlineFunctions, or RemoveUsedVariables will still try to remove the name and would also need to be fixed up.
Another approach is to use the source maps to remap the stack traces to the original source.
read the following section
https://developers.google.com/closure/compiler/docs/api-tutorial3#export
Two options basically, use object['functionName'] = obj.functionName or the better way
use exportSymbol and exportProperty both on the goog object, here is the docs link for that
http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.html
-- edit
ah, i see now, my first answer is not so great for you. The compiler has some interesting flags, the one which might interest you is DEBUG, which you can pass variables into the compiler which will allow you to drop some debugging annotations in via logging or just a string which does nothing since you are using simple mode.
so if you are using closure you can debug against a development version which is just a page built with dependiencies resolved. we also the drop the following in our code
if(DEBUG){
logger.info('pack.age.info.prototype.func');
}
VBScript on ASP Classic contains an "int" function. (It rounds numbers towards -∞.) Suppose that some excessively "clever" coder has created a global variable named "int". Is there any way to get at the original function? I've tried all manner of workarounds with scoping and dodgy execs, but no dice. I suspect that it is impossible, but I'm hoping that someone will know more about it than I do.
EDIT: Thanks for the responses. Since y'all asked, the global variable, called "Int" (though unfortunately, vbscript is not case-sensitive), is a factory for a class similar to Java's Integer. The default property is essentially a one-arg constructor; i.e. "Int(42)" yields a new IntClass object holding 42. The default property of IntClass in turn simply returns the raw number.
The creator was trying to work around the lack of proper namespaces and static methods, and the solution's actually pretty seamless. Pass in an IntClass where an int is expected and it will automatically trigger the default property. I'm trying to patch the last remaining seam: that external code calling "int" will not round properly (because the constructor uses CLng).
Not that I know of, getref only works on custom functions not on build-ins. I would suggest renaming the custom'int' function and update all references to this custom ones. You can use the search function visual studio (express) or any other tool of your liking for this. Shouldn't be to much work.
I didn't think reserved words would be allowed for function names or variables.
Duncanson's right. Do the pain and rename int. Chances are there are worse things going on than just this.
(why would someone make a global variable named int... that's going to take some thinking)
Or you can use CInt instead on Int
response.write trim(cint(3.14)) + "<br>"
Wrong!!
See NobodyMan comments