Get a reference to the script object - debugging

In V8 at least, in the debugger, you see local, script and global categorizing the variables.
I got a reference to global. All you do for that is set this on entry to a property to use later if need be.
However, I can't find how to save a reference to the script object. I think it exists because that's what the debugger is looping through in the watch window.

Before ES6, All declarations outside a function (and function declaration themselves) were properties of global object. After ES6, There are two kinds of global records:
Object record- Same as ES5.
Function declarations
Function generators
Variable assignments var
Declarative record - New
let, const, class, etc
Those in the declarative record are not accessible from the global "object", though they are globals themselves. They are accessible from the script, but the object/internal data structure holding the declarative records itself is not accessible or enumerable from inside the script. This declarative record is shown in v8 debugger as properties of script object.
References:
Global environment records
Related Answers:
ES6- What about introspection
Do let statements create properties on the global object

Related

Nifi: Reading external properties in custom Processor

I have updated the variable registry to point to a custom properties file and i am able to read those in my processors using expression language with out any issues.
How ever i want to read them in my Custom Processor's (extending the AbstractProcessor) onTrigger()
I tried flowFile.getAttributes() and context.getAllProperties() and it is not getting picked up.
Appreciate any inputs.
Thanks
To clarify, you want to reference the value of these externally-defined variables inside the application logic of your CustomProcessor#onTrigger() method?
You can:
Load the variable definitions by querying NiFiProperties#getVariableRegistryProperties() or NiFiProperties#getVariableRegistryPropertiesPaths. Once you have a reference to the variable definitions, you can parse and use them as you wish.
You can reference them via the flowfile attributes or processor properties if those attributes or properties support Expression Language and it is appropriately scoped. The PropertyDescriptor will list expressionLanguageSupported() and return an ExpressionLanguageScope, which is an enum consisting of NONE, VARIABLE_REGISTRY, and FLOWFILE_ATTRIBUTES (which also includes the VR).
I don't understand the scenario where you want your code to load custom variables that aren't controllable by the flow administrator, which would be populated via processor properties or flowfile attributes. If you really feel you need to access custom variables that aren't available via the context or flowfile, you can use Option 1 above, but you could also theoretically store those variables in environment variables, System properties, etc.

Class Module(.cls) vs Module(.bas) in Visual Basic

What is the difference between Class Module(.cls) and . Module(.bas) in Visual Basic ?
A Module(.bas) has methods and variables that can be used globally in your program and there is only a single instance of the data (similar to a Static method or field in C#). A Class Module(.cls) has properties and methods that usually can only be accessed when the object is instantiated, but can have multiple copies, each with differing data.
From MSDN: Visual Basic Concepts:
Classes differ from standard modules in the way their data is stored.
There is never more than one copy of a standard module’s data. This
means that when one part of your program changes a public variable in
a standard module, and another part of your program subsequently reads
that variable, it will get the same value.
Class module data, on the other hand, exists separately for each
instance of the class.
And from Devx.com: Class Module(.cls) vs. Module(.bas):
Deciding between a standard module and a class module is not a
decision based on performance, but one of design. The main difference
between the two is in the way that they handle data. A standard module
stores only one copy of the data. A class module encapsulates the data
within each instance of the class. That is, for each instance of the
class, the data exists separately.
The other main difference is the scope of variables and procedures
within the module. In general, any variables and procedures declared
as Public within a standard module are visible anywhere in the project
or external programs if the standard module is in a component.
Variables and procedures declared as Public within a class module can
only be seen through a reference to an instance of the class module.
The lifetime of data and procedures stored within a module is affected
by which type of module is used. The lifetime of the data and
procedures in a class module is defined by the lifetime of the object.
So data and procedures are available only if a reference to the object
exists. Data and procedures declared within standard modules are
available for the lifetime of the program.
Therefore, to answer your question, if you are writing a function that
you want available throughout the lifetime of the program and visible
to all code in the application, then place the function within a
standard module.
If the code is needed for lifetime of the program and is visible to all code in the application, then place the function within a standard module.
A standard module stores only one copy of the data. A class module encapsulates the data within each instance of the class. That is, for each instance of the class, the data exists separately.
In general, any variables and procedures declared as Public within a standard module are visible anywhere in the project.
Variables and procedures declared as Public within a class module can only be seen through a reference to an instance of the class module.
The lifetime of data and procedures stored within a module is affected by which type of module is used. The lifetime of the data and procedures in a class module is defined by the lifetime of the object. So data and procedures are available only if a reference to the object exists. Data and procedures declared within standard modules are available for the lifetime of the program.

Wrapping instance variables in accessor methods

Sandy Metz says (POODR book, page 26):
Because it is possible to wrap every instance variable in a method and to therefore treat any variable as if it's just another object, the distinction between data and a regular object begins to disappear.
I am not sure if I understand what she is explaining. When we define the accessors, we are wrapping the instance variables (data) on a method but methods are not objects. So what does she mean when she says that we can treat variables as if they're just another object?
The primary difference between data and objects is behaviour. Objects can modify their internal state without changing their interfaces, while data are static structures.
When we wrap data access within a method, we get the same benefits of an object - the interface remains static to consumers even if the underlying data structure needs to change.

QTP Descriptive Programmuing -Loading the objects created through function

I have 10 different test cases .I want to create different objects of SwfEdit, SwfButton etc just once say in function and then use those in different actions in QTP.
I tried creating a function and linked it to a test case,however it did not work.
So I am not sure what could be correct way to link all these objects across all the test cases.
If you insist on creating your objects in code instead of using the object repository, you'll need to store those objects in some type of global variable. A basic example might be for a function library:
' Declare your global variable to hold the object
Public MyObject
' Create your object from a function
Public Sub InitializeGlobalObject()
' Use Descriptive Programing to create your object
Set MyObject = Window("title:=something").Button("index:=0")
End Sub
This will allow you to create the object once and then refer to it by the variable
' Click the button
MyObject.Click
You may run into issues caching an object like this because it will tend to hold on to the last screen object that it matches, whereas the object repository will refresh the screen object each time you call it. You may need to call the 'Refresh' method on your object before you use it for the first time after it is displayed on the screen.
You should use object repository to add objects first if you are not intending to use descriptive language.
You should spy on each object and then add it.

MATLAB functions refusing to function depending on placement

I've written a very simple GUI in MATLAB that will convert temperatures. It is meant to serve as a tutorial for a class of students. A strange thing has happened though. As with any MVC design pattern, there is a model object, a view object and a controller function. In order to set the output field of the GUI (the converted temperature), you can run this line in the controller function itself:
set(views.outputTextField,'string',num2str(round(model.outTemp)));
where views.outputTextField is a GUI text field to display the converted temperature and model.outTemp is the converted temperature. Pretty straightforward. The views object has references to all the GUI uicontrols and this updates the field with the newly converted temperature in the model object.
However, I would rather have view functions in the view object, so I attempted to create a line like this:
views.updateOutputField = #()set(views.outputTextField,'string',...
num2str(round(model.outTemp)));
Same line as before, just that now it is an anonymous function in the view object. This way I could call the function from the controllers as simply views.updateOutputField(); and keep the view logic out of the controller logic. But this method won't work! (It will work with the get() function.)
Instead I have to do the following:
views.updateOutputField = #updateOutputField
function updateOutputField()
set(views.outputTextField,'string',num2str(round(model.outTemp)));
end
By separating out the function (redundantly) instead of just using an anonymous function, it works again. What!? This makes no sense to me. The view and model objects are global and the anonymous function works with get(). Does anyone have a clue what's going on here?
Both approaches are not equivalent. Values in the body of anonymous function (aka lambda) are being frozen, see example below:
>> ii = 2;
>> val = #() ii+2;
>> val()
ans =
4
>> ii=5;
>> val()
ans =
4
You can do following to make it work:
views.updateOutputField = #(outTemp) ...
If you want to know how MATLAB captures the workspace context, use function FUNCTIONS on anonymous function.
Your example is a little bit more complicated because your view and model exist in the nested workspace but the essence is the same.
As side note: kudos for teaching also an important design pattern (MVC) in Matlab class!
Mikhail has the right answer. I'll elaborate a bit...
From the MATLAB documentation for anonymous functions:
Anonymous functions commonly include
two types of variables:
Variables specified in the argument
list. These often vary with each
function call.
Variables specified in the body of the
expression. MATLAB captures these
variables and holds them constant
throughout the lifetime of the
function handle.
When you make a call to SET inside your anonymous function, you access fields of your two structure variables views and model. These values are held fixed at what they were when the anonymous function was created. That doesn't matter for the graphics handles stored in views, since these never change (unless you are deleting and recreating graphics objects). This is why calling GET in your anonymous function works fine, since it only uses the unchanged graphics handles in views. However, the values in model change, so you would want to pass them in to the anonymous function as an argument. For example:
views.updateOutputField = #(model) set(views.outputTextField,'String',...
num2str(round(model.outTemp)));
When you instead create your updateOutputField function, you are creating a nested function. Nested functions have access to the variables that exist in the outer function within which they are nested, which is why you don't have to pass views and model as arguments. When these variables change in the outer function, that change is visible in the nested function as well (unlike anonymous functions).

Resources