From what I am reading, a delegate instance is always defined with a class as an input or inside a class.
Why can't I define a delegate instance independently?
A delegate is a type, and you can define it at namespace scope (including the global namespace).
Since delegates are reference types, delegate instances always are placed on the managed (garbage collected) heap. Delegate instances can be created with the gcnew operator, the Delegate::CreateDelegate method, or using stack semantics syntax (C++/CLI only).
A reference variable of delegate type (including stack semantics syntax variables which wrap a permanently-bound reference, an instance on the heap, and an automatic call to IDisposable::Dispose) can exist as an instance or static member of a managed type, an automatic local variable, a static local variable, or (in C++/CLI) as a global (namespace scope) variable.
Related
I need to set properties on an object referenced by a Persistent handler. However, it seems like Persistent class doesn't have a Set method (unlike the Local class).
Does it mean that Persistent handlers are read only? What is the best way to set a property on a Persistent handler then?
Create a v8::Local from the v8::Persistent, then use that to call operations on the object (Set and/or others). Note that you need an active HandleScope for this.
v8::Persistent<v8::Object> my_persistent = ...;
v8::HandleScope scope(isolate);
v8::Local<v8::Object> obj = v8::Local<v8::Object>::New(isolate, my_persistent);
obj->Set(...);
(To be nitpicky: Local doesn't have a Set method either; what it does have is an operator-> overload that lets you call methods (including Set) on the thing that the Local refers to. If that thing isn't a v8::Object but e.g. a v8::Number, then it won't have a Set method.)
I am building an app using Swift2 and Realm to persist the data. The data relationships could be described as parent-to-child-to-grandchild objects. Each object has it's own subclass written with the same format. I am getting the runtime error "RLMObject subclasses cannot be nested within other declarations. Please move _TtCC12 ... to global scope.'" on the grandchild object. Any suggestions?
The error message is telling you that the declarations of your RealmSwift.Object subclasses must be at the outermost scope, and cannot be nested within other class or struct declarations, or function definitions.
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.
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.
Xcode 4.5 and later auto-synthesizes properties, making an instance variable with the underscore prepended on the property name. But how does this work in an NSManagedObject? They want you to use KVC primitive methods in your custom setters. So what happens if you set an instance variable via the underscore ivar inside the NSManagedObject? Won't that screw things up since it would bypass the KVC methods? Or is it safely doing this behind the scenes?
If you access the underscore instance variable directly, you are bypassing the work that NSManagedObject does for you. You should use the get and set accessor methods that NSManagedObject auto-generates for your attributes.
Apple's documentation states
When you access or modify properties of a managed object, you should
use these [accessor] methods directly.
You can implement your own accessor methods if required, but in that case, you have to do additional work beyond changing the value of the instance variable:
You must ensure that you invoke the relevant access and change
notification methods (willAccessValueForKey:, didAccessValueForKey:,
willChangeValueForKey:, didChangeValueForKey:,
willChangeValueForKey:withSetMutation:usingObjects:, and
didChangeValueForKey:withSetMutation:usingObjects:).
This should illustrate that you can't get the correct behavior simply by modifying the instance variable directly.
Note that unlike ordinary properties, NSManagedObject properties are not synthesized at compile time (hence the use of #dynamic for the implementation). Since compile-time synthesis isn't used, there are no synthesized instance variables available for you to set.
Instead, instances of NSManagedObject have a private internal instance of something similar to an NSMutableDictionary to store their state. The dynamically generated property accessors are wrappers for calls to KVC-like methods that access the private storage.