I'm referencing the bullet chart example at D3 v2.4.2 github repository.
I have a few question to help clarify what is happening in this example.
1) In the bulletChart function there are 8 declarations in the form
bullet.ranges = function(x) {}, bullet.markers = function(x) {} etc. Where is this bullet object coming from? Is it built into the library? I thought we had already set the variable ranges to the function bulletRanges, or are these 2 different ranges variables?
2) What is actually going on inside these functions?
3) Last question. When the bulletChart function starts executing does it start executing the bullet function as execution comes to it or does it wait for an explicit call? Because I never actually see bullet(g) called explicitly?
This library can be really confusing. Any help greatly appreciated.
1) The bullet at the start of the name refers to the function of the same name created in line 70. The calls add members to the object, which is also callable. It's basically a way of allowing to customise the returned object. In OO terms, bullet is an object and the functions define accessors for its members. The functions bulletRanges etc. provide similar functionality for the outer bulletChart function. In OO terms, think nested objects.
2) See 1. The functions are accessors for the variables that are defined inside the bullet function and allow to customise the behaviour this way. Again, the OO equivalent would be private members of an object that are exposed through accessors.
3) The return value of the bullet function is the callable object. This is what bulletChart returns. So the function call in the example happens in lines 19 and 36 (through a d3 function) by passing variable chart to the .call function. The assignment of chart in line 5 is what invokes the code that constructs the objects and callable closures.
If you're unfamiliar with Javascript, it might help to look up some tutorial material on its more exotic features, like closures.
Related
It seems like there are two styles for writing NEAR smart contracts in assembly script
Bag of functions like Meme Museum
Singleton style like Lottery.
I was wondering under what circumstance one style is recommended over the other.
When should you use one over the other? What are the advantages/disadvantages of each style?
The big differences is in initialization of the contract.
Bag of Functions (BoF)
For the first style, usually a persistent collection is declared at the top level. All top level code in each file is placed into a function and one start function calls each. The Wasm binary format allows to specify the start function so that anytime the binary is instantiated (e.i. loaded by a runtime) that function is called before any exported functions can be called.
For persistent collections this means allocating the objects, but no data is required from storage, until something is read, including the length or size of the collection.
Singleton
A top level instance of the contract is declared. Then storage is checked for the "STATE" key, which contains the state of the instance. If it is present storage is read and the instance is deserialized from storage. Then each "method" of the contract is an exported function that uses the global instance, e.g. instance.method(...), passing the arguments to the method. If the method is decorated with #mutateState then the instance is written back to storage after the method call.
Which To Use
Singleton's provide a nice interface for the contract and is generally easier to understand. However, since you are reading from storage at every method call, it can be more expensive.
The other advantage of the BoF is it's easier to extend as you can export more functions from a dependency.
However, it's also possible to use a combination of both as well.
So really it's whatever makes sense to you.
I'm trying to create a service where a user needs to operate over a data and can manipulate it in numerous ways, so I'm not aware of the manipulations at the time of compiling of my program. One way to achieve this is to give the user a function with data as param. Which landed me in the following direction.
Dynamically create a function
Dynamically linking a function after compiling it separately.
I'm open to suggestions. If you have other ways to achieve the end goal.
If you don't like this as an answer I can move to the comment section, but it's rather long that's why I put here in the answer section.
Dynamically Dispatched Method: The only way to have dynamically dispatched methods is through an interface. Methods on a struct or any other concrete type are always resolved statically.
Closure: Go supports anonymous functions, which can form closures. Anonymous functions are useful when you want to define a function inline without having to name it.
Dyncamically call method on Interface:
Please let me know if that helps you to understand the concept in golang.
I have just studied blocks it is good ,easy to use,helps in inline coding and keeps thing at one place .But I am not able to understand the following two points clearly.
1)How blocks are different from methods and delegates?
2)Advantages of using blocks over methods and delegates.Where are blocks more useful than delegates and methods.
Kindly explain and help me in understanding the concepts better.Thanks in advance!
A seemingly curious question as you ask:
1)How blocks are different from methods and delegates?
2)Advantages of using blocks over methods and delegates.Where are blocks more useful than delegates and methods.
After you wrote:
easy to use, helps in inline coding and keeps thing at one place
Regardless, though I maybe misunderstanding what you are after, here some further points to your own to consider in case they are helpful:
Instance methods and delegates are both associated with an instance of an object; so there is a self with instance variables, properties and other methods all of which can be referenced and used. Both come with accompanying state.
A block, like a function, is not associated with an instance of an object.
A block however differs from a function in that it can capture values and variables (those annotated with __block) from the method/function they are defined within. So they carry some state.
As to advantages of one over the others, it is really a question of picking the appropriate one for the scenario – none is "better" and the others. Decide what you need; adding behaviour to an object (method), passing an instance/method pair to provide some functionality (delegate), providing functionality based on values in the local scope (block), etc., etc.; and use the appropriate construct.
HTH
If you look at the examples on the official Mocha page, you'll see that they use the following describe syntax (for their BDD mode):
describe('Array', function() {
describe('#indexOf()', function () {
However, I can't seem to find anything (on the Mocha site or elsewhere) explaining why the second describe should be #indexOf() and not #indexOf or just indexOf. #indexOf seems to be a pretty common format (I've seen it in OSS code), but I've never seen anyone add parenthesis before. Then again, the Mocha people certainly know a lot more about testing than I do, so I've got to figure they use that syntax for a reason.
So, my question is, can anyone point me towards a resource that either:
is a "source of truth" (eg. somewhere on the Mocha site, or on some major testing site) saying that ____ is the default convention for describe (I realize this might not even be a JS source at all, since I know a lot of this stuff originated in RSpec)
describes the practical benefits of adopting this syntax
And if you could provide one of each (or one that does both) that'd be even better. Alternatively I'd also love a direct answer (ie. not a link to a resource), if its possible to just explain it directly.
Basically I just want to understand where this syntax came from and why I should use it (with both "because smart person ____ said so" and "because of practical reason ____" being legitimate answers).
I don't have an authoritative source regarding this. The #indexOf() is not special as far as Mocha is concerned. It treats it as it would treat any other text.
The only similar syntax I've ever encountered is JSDoc's syntax for referring to parts of a class. The #name syntax is used to refer to members that are used on instances of a class. In the JSDoc 3 syntax Array#indexOf is a meaningful expression which refers to the indexOf method used on an Array instance. Note how I do not have the parentheses though. I don't recall ever using parentheses in JSDoc 3.
The [documentation](MyConstructor#instanceMember
MyConstructor.staticMember
MyConstructor~innerMember) gives an example of instance, static and inner functions:
/** #constructor */
Person = function() {
this.say = function() {
return "I'm an instance.";
}
function say() {
return "I'm inner.";
}
}
Person.say = function() {
return "I'm static.";
}
var p = new Person();
p.say(); // I'm an instance.
Person.say(); // I'm static.
// there is no way to directly access the inner function from here
And shows how you would refer to them in JSDoc 3 documentation:
Person#say // the instance method named "say."
Person.say // the static method named "say."
Person~say // the inner method named "say."
JSDoc 3 reused this syntax (with one modification for inner methods) from JSDoc 2, which, as far as I can tell, predates Mocha.
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).