When I have a variable declared globally, I can re-use the same variable-name at function-level, without the compiler complaining about it.
Is there some way to disable this (similar to Option Explicit)?
No there is not.
The operation is perfectly valid and you can still access both by fully qualifying the reference, but by default it will try and access the closest in scope.
Related
I am using MethodCall.setsField() to try to set an instance field on another instance.
My generated class that is doing the field-setting, GC, is trying to set the value of an instance field in an instance of something it has created (CI). So the field's declaring type is CI; my field-setting code resides in GC (which is in the same package as CI but otherwise unrelated to it).
The ByteBuddy checks seem to indicate that although GC and CI are in the same package, GC must be assignable to CI in order to set this field! That greatly surprised me, but I am not a bytecode expert, and I might very well be overlooking something obvious. Could someone kindly explain why this check is necessary?
The method call sets the field implicitly on the this instance on which the method is invoked. For this to be possible, a non-static field must be declared by a super type of the type on which the method is invoked.
If you think this is too strict, please file an issue with an example of the code you are trying to generate, including the code to generate it which is currently failing. Maybe I am not thinking straight about this and if there's a restriction to be lifted, I would surely do it.
I'd like to have a project-wide variable which I can change during looking at that project. In other words, I'd like to get it affected whenever opening a file. Yes, I know .dir-locals.el exist in Emacs world. But I think it would be reset to the value set in .dir-locals.el whenever opening a file under that project.
Could I get some hints from you, please?
For this kind of thing you might want to use a function instead of a variable (directly). Specifically, use a getter and setter function.
All of your project code can invoke the getter function to get the value (which can be cached in a variable). And all of your code can invoke the setter function to change the value (which, again, can be cached in a variable).
These functions can be visible globally to your project. The cache variable would be accessed only by the getter and setter functions.
But as for code everywhere in your project being informed when the value gets updated and do what's appropriate with the new value whenever that happens, see #Phil's comment about the use of a variable - the same considerations apply.
You can have a hook in the setter function (or advise it), so that it does something additional (e.g. informs interested/subscribed code) whenever it updates the value.
For a variable you can do something similar using, as #Phils said in a comment, using add-variable-watcher.
For a user-option variable you can do something similar using :set and :get functions in the defcustom. (But those take effect only if changes are made using appropriate Customize functions or the Customize UI.)
You can eval in the dir-locals.el So, if you have a variable my-var that you want to be able to change with setq you could do something like
((nil . ((eval . (or (boundp 'my-var) (setq my-var 'default))))))
There are warnings about using eval in a dir-local though, since any code could be run there.
I am programming in elisp, and I would like to associate a symbol with a function such that an attempt to access the variable instead calls the function. In particular, I want to trigger a special error message when lisp code attempts to access a certain variable. Is there a way to do this?
Example: suppose I want the variable current-time to evaluate to whatever (current-time-string) evaluates to at the time the variable is accessed. Is this possible?
Note that I do not control the code that attempts to access the variable, so that code could be compiled, so walking the tree and manually replacing variable accesses with function calls is not really an option.
You are looking for the Common Lisp define-symbol-macro.
Emacs Lisp lacks this feature, you cannot accomplish what you are trying to do.
However, not all is lost if you just want an error on accessing a variable.
Just makunbound it and access will error out (unless, of course, someone else nds it first).
I don't think you can do that.
As Sam says, define-symbol-macro would be the closest thing in Lisp (tho you make it sound like the accesses might be compiled beforehand, in which case even define-symbol-macro would be powerless). The closest thing in Elisp would be cl-symbol-macrolet, but that is even more limiting than define-symbol-macro since it has to be placed lexically around the accesses.
I am getting sick of seeing the warning
"Declaration of 'index' shadows a global declaration"
index is defined in string.h. I don't think that it's required for anything I am using and I really don't want to change all the local vars from index to something else.
Anyone know of a way to find out how (by what path) string.h is included? Is it possible to prevent it from being included?
The index function is actually declared in /usr/include/strings.h, and is marked as removed as of POSIX issue 7. You can hide its declaration by setting the appropriate POSIX version with the compiler flag -D_POSIX_C_SOURCE=200809. This will also hide other functions deprecated in issue 7, like bcopy and bzero.
I find -Wshadow extremely annoying and rarely useful. Even if you solve this one case, there are bound to be others in the future, especially since system headers may define non-standard functions and variables which yours unintentionally shadow.
Personally, I would just disable the warning, and manually make sure no variables, functions, etc. are named the same as something being used.
in VB.NET it is possible to omit parentheses when you call a parameterless function. However this can be very confusing because developers could think that a statement is accessing a property instead of a method. this could result in a performance drop if you are calling the method again and again instead of storing the result in a temp variable.
is there an option in VS2008 or a compiler option to force parentheses on statements that are calling a method?
and if so, would it be also possible that VS will insert missing parentheses automatically if you "format document" (Menu: Edit - Advanced)?
thanks, toebens
No there is no such option in the VB.Net compiler. Parens are optional and there is no warning or error that exist for using a lack of them.
The other reason is that VB.Net is a language which tries to be flexible and get the syntax out of the way of the user. This type of restriction goes against this general philosophy.
Another issue to consider is that it's not a universally enforceable restriction. VB.Net allows for late binding scenarios whenever option strict is set to off. In these scenarios it is impossible for the VB.Net compiler to determine ahead of time if a particular call is a property, statement or not a valid call at all.