Assumed I have an aspect implementing IInstanceScopedAspect and I have this aspect applied to methods in a type. How can I initialize the aspects when creating the object with FormatterServices.GetUninitializedObject? The constructor is not executed and therefore I get a NullReferenceException when I execute the method where the aspect is applied.
Is there a PostSharp API which can be used to initialize the object's aspects ?
There is a InitializeCurrentAspects method available for exactly this scenario, as documented here; http://doc.sharpcrafters.com/postsharp-2.0/Default.aspx##PostSharp-2.0.chm/html/M_PostSharp_Aspects_AspectUtilities_InitializeCurrentAspects.htm
Related
in the OPAL framework, is it possible to manually create an annotated method?
I currently have the following code:
Method(0, "signaturePolymorphicMethod",
MethodDescriptor(ObjectType("java/lang/Object"), VoidType), Seq())
and I want to add the annotation
#java.lang.invoke.MethodHandle$PolymorphicSignature
to this method. How can I do this?
Annotations are generally stored using the JVM's general "Attributes" mechanism.
In this case the annotation is a non-public inner class of MethodHandle with the "Runtime Retention Policy". Hence, to mark a method as having a "Polymorphic Signature" it is necessary to add the RuntimeVisibibleAnnotations_Attribute to the respective method's attributes table. However, given that the visibility of the annotation is limited to the java.lang.invoke package this is (in this specific case) probably rarely useful. Nevertheless, it is possible to query methods in the respective package
The documentation says this is allowed:
ClassMethod GetContacts() As %ListOfObjects(ELEMENTTYPE="ContactDB.Contact")
[WebMethod]
I want to do this:
Property Permissions As %ListOfObjects(ELEMENTTYPE="MyPackage.MyClass");
I get an error:
ERROR #5480: Property parameter not declared:
MyPackage.Myclass:ELEMENTTYPE
So, do I really have to create a new class and set the ELEMENTTYPE parameter in it for each list I need?
Correct syntax for %ListOfObjects in properties is this one
Property Permissions As list of MyPackage.MyClass;
Yes, a property does sometimes work differently than a method when it comes to types. That is an issue here, in that you can set a class parameter of the return value of a method declaration in a straightforward way, but that doesn't always work for class parameters on the class of a property.
I don't think the way it does work is documented completely, but here are some of my observations:
You can put in class parameters on a property if the type of the property is a data-type (which are often treated differently than objects).
If you look at the %XML.Adaptor class it has the keyword assignment statement
PropertyClass = %XML.PropertyParameters
This appears to add its parameters to all the properties of the class that declares it as its PropertyClass. This appears to be an example of Intersystems wanting to implement something (an XML adaptor) and realizing the implementation of objects didn't provide it cleanly, so they hacked something new into the class compiler. I can't really find much documentation so it isn't clear if its considered a usable API or an implementation detail subject to breakage.
You might be able to hack something this way - I've never tried anything similar.
A possibly simpler work around might be to initialize the Permissions property in %OnNew and %OnOpen. You will probably want a zero element array at that point anyway, rather than a null.
If you look at the implementation of %ListOfObjects you can see that the class parameter which you are trying to set simply provides a default value for the ElementType property. So after you create an instance of %ListOfObjects you could just set it's ElementType property to the proper element type.
This is a bit annoying, because you have to remember to do it every time by hand, and you might forget. Or a maintainer down the road might not now to do it.
You might hope to maybe make it a little less annoying by creating a generator method that initializes all your properties that need it. This would be easy if Intersystems had some decent system of annotating properties with arbitrary values (so you could know what ElementType to use for each property). But they don't, so you would have to do something like roll your own annotations using an XData block or a class method. This probably isn't worth it unless you have more use cases for annotations than just this one, so I would just do it by hand until that happens, if it ever does.
I have use the type dynamic, a new type in .NET 4.0.
I want to use a dynamic type because I want to use some types that in advance I don't know what type is, but I know that all this possible type has some common methods.
In my case, I am using self tracking entities in entity framework 4.0, and I know that all the entities has the methods markedXXX (to set the state of the entity).
Through the dynamic object that I created, I can access and set the properties of one of this entities, but when I try to execute the MarkedAsXXX method I get an exception that says that the object has not definied the method.
I would like to know how to access to this methods. Is it possible?
Because I have a function that can access to the original values and set this values to the current one, but I need to set the entity as Unchenged.
Thanks.
I want to use a dynamic type because I want to use some types that in advance I don't know what type is, but I know that all this possible type has some common methods.
That suggests you should create an interface with those common methods, and make all the relevant types implement the interface.
Through the dynamic object that I created, I can access and set the properties of one of this entities, but when I try to execute the MarkedAsXXX method I get an exception that says that the object has not defined the method.
It's possible that this is due to explicit interface implementation. If the types have those methods declared as public methods in the normal way, it should be fine.
If you really want to use dynamic typing with these types, is there some base interface which declares the MarkedAsXXX methods, which you could cast the objects to before calling those methods? (I'm not familiar with the entity framework, so I don't know the details of those methods.)
Basically, I would try to avoid dynamic typing unless you really need it, partly because of edge cases like this - but if explicit interface implementation is the cause, then casting to that interface should be fine.
If you define an interface to the dynamically generated classes you can call the methods without the hassle of reflection calling.
As we know, Scala generates getters and setters automatically for any public field and make the actual field variable private. Why is it better than just making the field public ?
For one this allows swapping a public var/val with a (couple of) def(s) and still maintain binary compatibility. Secondly it allows overriding a var/val in derived classes.
First, keeping the field public allows a client to read and write the field. Since it's beneficial to have immutable objects, I'd recommend to make the field read only (which you can achieve in Scala by declaring it as "val" rather than "var").
Now back to your actual question. Scala allows you to define your own setters and getters if you need more than the trivial versions. This is useful to maintain invariants. For setters you might want to check the value the field is set to. If you keep the field itself public, you have no chance to do so.
This is also useful for fields declared as "val". Assume you have a field of type Array[X] to represent the internal state of your class. A client could now get a reference to this array and modify it--again you have no chance to ensure the invariant is maintained. But since you can define your own getter you can return a copy of the actual array.
The same argument applies when you make a field of a reference type "final public" in Java--clients can't reset the reference but still modify the object the reference points to.
On a related note: accessing a field via getters in Scala looks like accessing the field directly. The nice thing about this is that it allows to make accessing a field and calling a method without parameters on the object look like the same thing. So if you decide you don't want to store a value in a field anymore but calculate it on the fly, the client does not have to care because it looks like the same thing to him--this is known as the Uniform Access Principle
In short: the Uniform Access Principle.
You can use a val to implement an abstract method from a superclass. Imagine the following definition from some imaginary graphics package:
abstract class circle {
def bounds: Rectangle
def centre: Point
def radius: Double
}
There are two possible subclasses, one where the circle is defined in terms of a bounding box, and one where it's defined in terms of the centre and radius. Thanks to the UAP, details of the implementation can be completely abstracted away, and easily changed.
There's also a third possibility: lazy vals. These would be very useful to avoid recalculating the bounds of our circle again and again, but it's hard to imagine how lazy vals could be implemented without the uniform access principle.
Exactly what the topic title says,
In which cases would you prefer using public functions to change local variables over just defining that variable as public and modifying it directly?
Don't expose the data members directly: using opaque accessors means you can change the implementation at a later date without changing the interface.
I should know. I take the short cut from time-to-time, and have had occasion to regret it.
Obviously if you want changing the variable to have some other effect on the object's state (like recalculating some other property of the object) you must use a mutator function.
If it's possible to set the variable to something that places the object in an invalid state, you should probably also use a mutator function. This way you can throw an exception (or return an error, or just ignore) if something illegal is about to happen. This does wonders for debugging.
But if some variables can be modified with mutator functions, and others are public, the programmer needs to keep track of which is which. This is a waste of time and effort so in some cases it's easiest to just use mutator functions for everything.
If you look at an object purely in term of service, you realize that exposing a variable is not a good way to expose those services.
The API must reflect what the object is all about (for it to achieve a high cohesiveness), and if you define a setValue(...), it is not so much because you need a way to -- today -- changes a variable, but because it makes sense for the object to expose this service.
So:
Don't provide accessors or mutator function to every single member of every single class you write. Only provide accessors/mutator functions if the accessors/mutator methods are a sensible and useful part of the class's interface (API).
Don't think of these methods as accessors or mutators. Instead, think of them as methods that access or mutate a certain abstract property of the object that happens to be represented by a single member today, but may be computed in a more complex manner tomorrow.
You should mention what language you are dealing with, since that will affect the answer.
Your first thought should be about the API to your class. If you want to keep that API stable (and you should!), then consider how you might change today's simple variable into a full-blown method later.
In many languages, you can't change a variable to a method without changing the calling code. C, C++, and Java fall into this category. Never use public variables in these languages, because you won't have any wiggle room later.
In Python, you can change a variable to a property without changing the callers, so you don't have to worry up front: use public variables.
C# I believe has properties that can let you change variables to methods transparently, but I am not sure.
If you want to change a variable inside a class, your best doing it through Properties.
Its not good practice to have variable's modified on the outside.
Think of future development too. You could put some logic behind a Property without changing the whole program.