In any programming language, is the type of referencing environment dependent on the scoping? i.e. a static scoped language would necessarily have static referencing environment?
Yes. The referencing environment is the collection of variables which can be used. In a static scoped language, you can only reference the variables in the static reference environment.
A function in a static scoped language does have dynamic ancestors (i.e. its callers), but it can not reference any variables declared in that ancestor.
Related
I have a number of individually named Hashtables residing in the ApplicationScope space. I'm struggling with the Hashtable's GET(String) method when used in a different Class elsewhere in my app.
My syntax is yelling --> "The method get(String) is undefined for the type FooterLinkBean".
My JAVA code containing this error is --> packedString = gr_footerlink.get(searchKey); where the 'searchKey' is my 'Key' value that I'm attempting to query against my Hashtables named 'Gr_footerlink.get'.
I'm trying to retrieve the value (which is a pipe-delimited string of text values) that I'll later split into their individual components. Both my Hashtables 'Gr_footerlink.get' structure is built in the ApplicationScope space while my method I'm using to call it resides in a SessionScope Managed bean.
I can successfully query the Hashtable immediately after it is built and populated by virtue of writing debug messages into Greg's Xpages Debug Toolbar. However, when I attempt to query the same Hashtables "outside" from a different Class file, it starts yelling at me.
Clearly, I'm confused.
I've tried instantiating a object from by GR_footerlink Bean within my dialogBoxModal Class, thinking that would be enough to expose it's methods, although that seems logical, I am probably not executing it correctly (novice JAVA developer).
What scope does <cfquery> use by default on a .cfm template? Will they be collected by the gc once a request ends?
The default scope in .cfm is VARIABLES.
<cfquery name="x">
is equivalent to
<cfquery name="VARIABLES.x">
Not using the scope in front of a variable makes ColdFusion look for the variable in other scopes (starting with VARIABLES for the above case). There are exceptions based on the context, even in a .cfm template (local variables). You can learn more about it in the official docs, here
and here It's worth knowing this.
And yes, when the request finishes, the variables are marked for garbage collection. You do not have to explicitly "delete" or "null" them.
I am working on some VBA code written by another individual within Excel. They created a
Const pass = "passwordkey"
in ThisWorkbook.
Can I reference this in a userform code, another sheet code, or module code? If yes, how?
I am wanting to essentially do this in the areas mentioned:
ActiveWorkbook.UnProtect (pass)
(but it is not working...)
Thank you!!
Use the Public keyword. Public Const pass = "passwordkey"
Edit: I just noticed you said this was in ThisWorkbook. You cannot use the public keyword there. You need to place this in a standard module
Scope of variables in Visual Basic for Applications
Summary
The scope of a variable is determined at the time the variable is declared. In Microsoft Visual Basic for Applications, the three scopes available for variables are procedure, module, and public. The "More Information" section of this article describes each scope in detail.
Public scope
Public variables have the broadest scope of all variables. A public variable is recognized by every module in the active workbook. To make a public variable available to other workbooks, from a new workbook select the workbook containing the public variable in the Available References box of the References dialog box (from a module sheet, click References on the Tools menu).
A public variable, like a module-level variable, is declared at the top of the module, above the first procedure definition. A public variable cannot be declared within a procedure. A public variable is always declared with a "Public" statement. A public variable may be declared in any module sheet.
It is possible for multiple module sheets to have public variables with the same name. To avoid confusion and possible errors, it is a good idea to use unique names or to precede each variable name with a module qualifier (for example, in a module named "Feb_Sales" you may want to precede all public variables with the letters "FS").
It appears clear from Hejlsberg, et. al. 2011 4th Ed. C# Programming Languages that you can make a 'new' function the same name as an existing class member. I can somewhat see why this might be useful , in some kind of versioning conflict scenario,
But what I don't get is why you would ever want to make the 'new' function or the 'shadow' function; private
There are few differences between those.
1. Shadowing is bad programming practice according to OOPs concepts.
2. In shadowing signature could be different.
3. In Shadowing both Derived class methods and Base Class methods are available for use.
In C#, a method in a derived class can have the same name as a method in the base class. You can specify how the methods interact by using the new and override keywords. The override modifier extends the base class method, and the new modifier hides it.
We use early-bound class for development. But occasionally we use attribute names.
There is a way to do it using reflections, but reflections are not allowed in sandbox plugins.
What are the approaches to getting an attribute from proxy types without relying on reflections?
Opportunity.OpportunityId.AttributeName
You have a couple options:
You can use a RetrieveEntityMetadata to the list of attributes that the entity contains. You won't be able to use any early binding here, but you can inspect the results at run time to see what are valid attributes for the entity.
You could also create a simple utility that uses reflection to auto-generate a class or enum that contains the list of attributes before you actually deploy. Just add the class to your plugin dll and you'd have the benefits of early binding of entity attributes when developing your plugin, without having to do reflection at runtime.