Is it possible to intercept class constructor and destructor calls using PostSharp? I would like to create active instances counter for classes.
You can use OnMethodBoundaryAspect on constructor and destructors. Note that classes don't have destructors by default in C# and VB, and destructors are called at a non-deterministic moment.
Remember that constructors can be called in chain, and the aspect is going to be applied on every constructor in the chain.
Related
How does a main method gets called in scala ? Why does a main method gets called in when it is written only in object but not in class ?
Because the specification says so:
A program is a top-level object that has a member method main of type (Array[String])Unit. Programs can be executed from a command shell. The program's command arguments are passed to the main method as a parameter of type Array[String].
The main method of a program can be directly defined in the object, or it can be inherited.
It speaks only about top-level objects, not classes. If you define a main method in a class, then it will be just an ordinary method that you can invoke on the instances of this class. Unless you define a top-level object that inherits the main from this class / trait, this method called main will not be treated as an entry point of the application.
The main method must be a static method. In Scala to create a static method you put it in an object. Methods in a class are not static.
In the scala language they decided to separate class, which hold only instance behavior and state, and object which hold static behavior and state. This is different from java where classes hold both instance and static members where something is made static using the static keyword.
It is because in scala the only way to define a method static is object class. And also it is necessary only one instance of main class is created , not multiple instances. That's why it is object class
I was going through basics of UVM tutorials. Everywhere I read the transaction objects are always extended from uvm_sequence_item and not uvm_transaction since uvm_sequence_item has additional features like transaction id, etc. If that is the case, why is the uvm_transaction class even there in the UVM class hierarchy?
Who is using uvm_transaction other than uvm_sequence_item extending from it?
Is it because of legacy?
This is what the UVM Class Reference says about this:
"The uvm_transaction class is the root base class for UVM transactions. Inheriting all the methods of uvm_object, uvm_transaction adds a timing and recording interface.
This class provides timestamp properties, notification events, and transaction recording support.
Use of this class as a base for user-defined transactions is deprecated. Its subtype, uvm_sequence_item, shall be used as the base class for all user-defined transaction types."
If you refer uvm class hierarchy (Link:[https://www.google.co.in/search?biw=1366&bih=620&tbm=isch&sa=1&btnG=Search&q=uvm+class+hierarchy#imgrc=Laxc9UWNpnGTpM%3A][1] ) then you find out that uvm_transaction parent class while uvm_sequence is child class.
So, child class can access all the property of parent class.
But parent class can not access child class property.
uvm_sequence_item has its own functionality like get_sequencer_id,set_sequencer_id, get_root_sequence.
These methods used by sequencer internally in case of layer sequences.
You call sequence by start method, uvm_do family or config_db.
Each of these method call start_item(req) and finish_item(req).
task start_item(uvm_sequence_item item)
task finish_item(uvm_sequence_item item)
If you observes data type in first argument in both the function is uvm_sequence_item.
There are total eight uvm classes.
(1) uvm_driver.svh
(2) uvm_push_driver.svh
(3) uvm_sequencer.svh
(4) uvm_push_sequencer.svh
(5) uvm_sequencer_library.svh
(6) uvm_sequencer_analysis_fifo.svh
(7) uvm_sequence.svh
(8) uvm_sequencer_param_base.svh
These classes are parameterized with uvm_sequence_item not with uvm_transaction.
If you use uvm_transaction instead of uvm_sequence_item then ti will shout an error(set_sequence_id not found which is property of uvm_sequence_item not uvm_transaction ) from uvm_sequencer_param_base.svh.
So, communication of sequence,sequencer and driver is not completed.
In most of the cases which I observe if you have a code in which you are not going to use uvm_sequencer then you can use uvm_transaction it will not shout an error.
But if your code contains uvm_sequener and you use uvm_transaction then it will shout an error (Could not find member 'set_sequence_id').
Note that from uvm_transaction class, uvm_sequence_item as well as uvm_objects are inherited. So, the static behaviour and non-static behaviour (so to say) class hierarchy all starts from uvm_transaction.
Now, I can add whatever functionality I want to, to uvm_sequence_item so that every inheritor of uvm_sequence_item can get this. I can do this without modifying uvm_transction_item. Otherwise, any change in uvm_transaction would lead to unwanted functionality in the component class hierarchy (static behaviour) and can even lead to unintended side effects.
PS: one of the difference between other OOPs languages and SV is that multiple inheritance is not allowed in SV. For example, in case of C++, I can inherit from 2 classes in a new class. This is not allowed in SV. So, the only way one can get the properties of uvm_transaction as well as from uvm_sequence_item is by inheriting from uvm_sequence_item. This maybe the source of your confusion.
Racket's documentation only partially describe what augment and pubment do: augment makes a method that executes after the superclass's version of that method, while pubment makes a method that will implicitly have the augment property if it is defined in a child class.
The docs say absolutely nothing about overment and augride, and I can't guess what they would do based on their names. What are they, and what is the difference between them?
The relatively large family of inheritance functions for Racket's class system is, as you describe, a little confusing, and their somewhat cutesy names don't always help.
In order to understand this, Racket provides two separate mechanisms for method inheritance.
public methods correspond to the classical idea of public methods in other OO models. Methods declared with public may be overridden in subclasses, unless they're declared final, in which case they cannot.
pubment methods are similar, but they cannot be overridden, only augmented. Augmenting a method is similar to overriding it, but the dispatch calls the superclass's implementation instead of the subclass's.
To clarify the difference between overriding and augmentation, when an overridden method is called, the overriding implementation is executed, which may optionally call the superclass's implementation via inherit/super. In contrast, in an augmented method, the superclass's implementation receives control, and it may optionally call the subclass's implementation via inner.
Now, we're also provided public-final, override-final, and augment-final. These are pretty simple. Declaring a method with public-final means it can neither be augmented nor overridden. Using override-final overrides a superclass's public method, but it doesn't allow any further overriding. Finally, augment-final is similar, but for methods declared with pubment, not public.
So then, what about the two weird hybrids, overment and augride?
overment can be used to implement methods initially defined with public. This "converts" them to augmentable methods instead of overridable methods for all the class's subclasses.
augride goes in the opposite direction. It converts an augmentable method to one that is overridable, but the overriding implementations only replace the augmentation, not the original implementation.
To summarize:
public, pubment, and public-final all declare methods that do not exist in a superclass.
Then we have a family of forms for extending superclass methods:
override and augment extend methods declared with public and pubment, respectively, using the relevant behaviors.
override-final and augment-final do the same as their non-final counterparts, but prevent further overriding or augmentation.
overment and augride convert overridable methods to augmentable ones and vice-versa.
For another, fuller explanation, you might be interested in taking a look at the paper from which Racket's model was derived, which is quite readable and includes some helpful diagrams.
Why can we have a virtual destructor but not virtual constructor?
The constructor chain can be determined at compile time, because you use new ClassName() always from the most specific class possible.
However you call destructors on possibly parent classes if you use polymorphism, so you can't know at compile time where to start the chain from. You need a virtual function to always call the right one (or you'd end up with potentially uncleaned resources in the most specific classes).
When running FxCop I get the error that interface methods should be callable by child types.
The resolution states the following:
"Make 'MenuPreview' sealed (a breaking change if this class has previously shipped),
implement the method non-explicitly, or implement a new method that exposes
the functionality of 'IComponentConnector.Connect(int, object)'
and is visible to derived classes."
I get this for all classes the derive from Window or some other UI class. Is this a red herring that I can ignore, or is there something I should be doing?
I think the issue is that if an interface is implemented explicitly, it will be impossible for a derived class to both change the interface behavior and make use of the base-class behavior. A common pattern to get around this difficulty in cases where explicit interface implementation would be required is to have the interface do nothing but call a protected virtual method, and have any derived classes that wish to override the behavior of the interface do so by means of the protected virtual method.
Consider IDisposable.Dispose(). If the code in an explicit implementation were actually responsible for performing the disposal, there would be no way for a derived class to add its own dispose logic except by reimplementing IDisposable, and there would be no way for a class which reimplemented IDisposable to access its parent's Dispose method. Although Microsoft could have had IDisposable.Dispose call a protected function with a different name, it opted to use the same name but add a dummy parameter of type Boolean.