On my blueprint, I defined a method buy_hotdog(&mut self, payment: Bucket) and when instantiating my component, I defined the access rules like this:
let access_rules = AccessRules::new()
.method("buy_hotdog", rule!(require(customer.resource_address())), AccessRule::DenyAll)
.default(AccessRule::AllowAll, AccessRule::DenyAll);
But how can a customer actually call this method?
your resource_address is also known as badge token address.
The caller of "buy_hotdog" should have that badge token(s) before calling that function.
Related
How are an object INSTANCE and a Companion object different and which situations should they be used in.
ObjectName.INSTANCE.iAmStaticMethod();
ClassName.Companion.iAmStaticMethod();
ClassName.Companion can be used also for accessing a non static method
iAmStaicMethod() is a static function and iAmNonStaticMethod() is a non-static function.
So, to call the above methods in Java, write the below code:
ClassName.iAmStaticMethod(); // works fine
ClassName.iAmNonStaticMethod(); // error: not a static method
ClassName.Companion.iAmStaticMethod(); // instance method remains
ClassName.Companion.iAmNonStaticMethod(); // the only way it works
Vue.js official docs about plugins describes global methods and properties and Vue instance methods.
// 1. add global method or property
Vue.myGlobalMethod = function () {
// some logic ...
}
// 4. add an instance method
Vue.prototype.$myMethod = function (methodOptions) {
// some logic ...
}
But it isn't clear which of this approach is better fit to define global functionality? Can someone explain difference or indicate some resource about different use cases of this two approaches?
An instance method will have an instance (this) to be called from an operate on. A global-on-Vue function would have Vue itself as its this, which probably means you wouldn't want to use this in it.
So: instance method if it should operate on an instance, global function if it is some sort of utility that doesn't operate on a Vue instance.
If I have a public method, I can call it inside its class using both $.name and self.name:
class TEST {
has Int $.a;
method b($x) {
return $!a * $x;
}
method c($y) {
return self.b($y) * 3; # or $.b($y)
}
}
my $m = TEST.new(a => 10);
say $m.c(2); # 60
But if I make b a private method, I only can call it with self!b, not $!b, otherwise I get the following error message:
Attribute $!b not declared in class TEST
What's behind this rule? What are the rules of calling a method inside its own class?
An attribute can always be referred to as $!foo in a class. If you do that, than the code will be generated to directly access the attribute itself, and any classes subclassing your class will not be able to change this behaviour.
If you use has $.foo in the declaration of a class, it means that a public accessor (and if you add is rw it can also function as a mutator).
When you use $.foo in your code otherwise, it is exactly the same as $( self.foo ). This means that it will call the method foo on self, and itemize the return value (make it a single "thing" if it wasn't yet). This will go wrong if you defined your attribute with $!foo and you did not supply a method foo yourself.
This goes even further: $.bar really means self.bar: you only need to have a method existing by the name bar, which may not be related to any attribute at all.
If you define a private method !baz, the ! just indicates the privacy of the method, which means you need to call it indeed as self!baz. There is no short syntax for it.
Personally I dislike the fact that you can say $.zippo even if zippo is not an attribute. But I'm afraid that ship has sailed. But this behaviour is now causing you confusion :-(
So what's behind the rule for not having a short syntax for calling a private method? Not sure, I guess really that $!foo was already taken to mean direct access to the attribute, and provide you with a compile time error if the attribute doesn't exist.
Hope this answers your question!
I'm creating my own template based widgets and I was trying to pass some objects through the constructor on creation like this
var widget = new myWidget(obj1, obj2, obj3);
where my constructor of the widget looks like
constructor: function(param1, param2, param3)
However I was getting some errors and found they were due to _WidgetBase functionality (specifically the create method) that is expecting something special in the first and second parameters.
create: function(params, srcNodeRef)
So in order to avoid my parameters nuking the params, and srcNodeRef that was expected in position one and two, I had to move my parameters to after the second position like this
constructor: function (params, srcNodeRef, myParam1, myparam2, myParam3)
But naturally this is not an expected way to solve this compared to the usual way to instantiate objects in normal object oriented languages (ex. c#)
My question is, is there a recommended pattern for passing initialization parameters to a custom widgets constructor, that avoids this issue of having to remember the first and second parameter positions are reserved?
NOTE:
An important note is that whatever parameters I send into the widget, must be acted on or made available before postCreate executes, just like it is if I passed them to the constructor.
Actually, there is a "dojo" way to pass parameters into your widget:
var widget = new myWidget({obj1: obj1, obj2: obj2});
In instance of your widget these object will refer to
this.obj1, this.obj2. You don't have to override constructor.
Some comments from dojo source of _WidgetBase on this topic:
//////////// INITIALIZATION METHODS ///////////////////////////////////////
/*=====
constructor: function(params, srcNodeRef){
// summary:
// Create the widget.
// params: Object|null
// Hash of initialization parameters for widget, including scalar values (like title, duration etc.)
// and functions, typically callbacks like onClick.
// The hash can contain any of the widget's properties, excluding read-only properties.
// srcNodeRef: DOMNode|String?
// If a srcNodeRef (DOM node) is specified:
//
// - use srcNodeRef.innerHTML as my contents
// - if this is a behavioral widget then apply behavior to that srcNodeRef
// - otherwise, replace srcNodeRef with my generated DOM tree
},
=====*/
I +1'd Kirill's answer as that's the easiest. But from the other comments it sounds like you might need to massage the input or initialize other variables based on the input.
If so, take a look at the postMixinProperties lifecycle method and override it in your widget. If your widget is templated and the template expects the massaged data, you'll need this. In here you refer to your properties with this as you expect.
postMixInProperties: function(){
// summary:
// Called after the parameters to the widget have been read-in,
// but before the widget template is instantiated. Especially
// useful to set properties that are referenced in the widget
// template.
// tags:
// protected
},
Don't forget to invoke this.inherited(arguments); in here as you should in all of the dijit lifecycle methods.
Defining setters for you properties is another way to massage these properties. You'll want this if a template will use these properties. Example of a setter from the Writing Widgets page. So here 'open' would be the name of the parameter as passed to the contructor, or in a widget template.
_setOpenAttr: function(/*Boolean*/ open){
this._set("open", open);
domStyle.set(this.domNode, "display", open ? "block" : "none");
}
I would like to use TComInterface to replace raw pointer.
My current code is:
{
TComInterface<IStoreNamespace> pStore;
if (SUCCEEDED(CoCreateInstance(CLSID_StoreNamespace, NULL, CLSCTX_INPROC_SERVER, IID_IStoreNamespace, (LPVOID*)&pStore)))
{
if (SUCCEEDED(pStore->Initialize(Form1->Handle, 1)))
{
//pStore->CallOtherMethods...
}
}
// Release()'d automatically?
}
If I understood correctly this overwrites the pStore pointer with new pointer so it doesn't call pStore->Release(); automatically from eventually previous instance using pStore.
Under what conditions is Release() called? I believe it may be when the variable goes out of scope even if I initialized it like this. And what is the proper way to initialize pStore in above example so it doesn't just overwrite pointer but also calls Release() first?
TComInterface calls Release() on its internal interface when TComInterface goes out of scope and gets destructed. You can also call the TComInterface::Unbind() method if you want to manually Release() the interface sooner. TComInterface also calls Release() on its current interface if you assign a new interface pointer (or other TComInterface instance) via the = assignment operator.
TComInterface overrides the & operator to return a pointer to its internal interface, so you have to make sure that TComInterface is not holding an active interface before you call CoCreateInstance() (or anything else that will copy a new interface into TComInterface) or else the preview interface will be leaked and not released. TComInterface's default constructor sets the internal interface to NULL, so you don't usually have to worry about that, unless you re-use the same TComInterface variable multiple times, such as when using interface enumerators in a loop.