I try to serialize objects with their private attributes, in Flex.
The introspection API does not seem to allow it:
"The describeType() method returns only public members. The method does not return private members of the caller's superclass or any other class where the caller is not an instance."
Is there another way for an instance to know the name of its private members?
Unfortunately, the describeType() method is the only way to do introspection in Flex. People have written wrappers around it, and if you want to do introspection then I'd recommend as3-commons-reflection, but there is no way to list the private attributes of a class and no way to access them even if you could list them.
Related
I've been using dart for quite a while now. If I want to implement dynamic getters, setters and functions for objects of a class, I can make use of the noSuchMethod-method. But what if I now want to have such a dynamic getter, setter of method on class layer? In Ruby, for example, if one wants to implement a dynamic class method, one would define the method_missing-method on the class object, like for example:
class Test
def self.method_missing
//Do some matching, return result or error
end
end
How would I achieve this in Dart?
I don't think you can do this in Dart without mirrors/reflection.
I also don't think this is very useful.
You can't call a static method on a 'dynamic' type and therefore you can't mock static methods.
If you need this you should just make it a normal method instead of a static one.
You can just override noSuchMethod as noticed here
A friend asked me this and not sure how to understand. Prolly a simple answer.
He has the following
Public Class TestClass
Public Sub Setup()
MsgBox ("Hello")
End Sub
End Class
Based on that example, what type of member is Setup, in relation to the TestClass class?
I think it it might be an instance member. Because a class is just a collection of instances (methods, properties, etc) within the class.
Correct?
This would be an instance method as opposed to a class method (static methods).
When a field, method, property, event, indexer, constructor, or destructor declaration does not include a static modifier, it declares an instance member.
More information here.
Initially my answer said that a member is the same as a field. According to the MSDN link above this was not entirely correct so I adjusted it. You'll also notice that they use the term static member instead of instance member.
Terminology is a very tricky subject and you'll notice people use many different descriptions for the same subject. This is further amplified when you take other languages in consideration and the terminology there.
It is an instance method, but not because a class is a collection of instances.
It is an instance method because TestClass is not shared (static), and must be instantiated. That is, there must be a instance of TestClass available to use its method Setup(). Conversely, with a Shared class, you do not need an instance of TestClass to use Setup(), it would be a Shared method and not an instance method.
That is academic, however, since VB does not support static classes (Shared Classes), but does support shared methods, the effective difference is that declaring Setup() as Public makes it an instance method, or declaring it as Shared would make it a static method.
Im using Oracle, BlazeDS, Java & Flex. I have an ArrayCollection containing data from a small database table. This table won't be the subject of much change. I want to use this ArrayCollection accross different mxml files to fill e.g. ComboBoxes etc.
The reason for asking, is that doing a database call for each time a fill a ComboBox etc is slow and seems unnecessary. I tried doing this once in the "main" .mxml file, but then the variable wasn't accessible where i needed it.
What is the best approach for accomplishing this task? What is the best way of making a variable accesible across .mxml files? :)
[Bindable] public static var yourArrayCollection:ArrayCollection
That should make it visible anywhere but using static variables is normally not a good idea.
You could also implement a singleton instance to persist a variable if you do not want to make it static and need to reference other functions etc - but I think the static variable should do fine.
If this is a larger application, I'd recommend looking at Parsley: http://www.spicefactory.org/parsley/. With Parsley, you could add the array collection to the context and simply inject it whenever you need to reference it. The array collection should be populated during application startup and can be updated as needed.
There basically are two ways. The singleton way, and the static class way. A singleton is a class that is only instanciated once, through a mechanism described here, for instance. A static class is a bit different from a regular class : you will not instanciate it, first of all.
For more information about how implement a singleton in ActionScript 3 : here.
For more information about static classes and variables : here.
You can just make it public member of some class and import that class in all MXML-based classes:
public class DBWrapper {
[Bindable]
public var ItemList:ArrayCollection;
}
I usually make it a static member of a Globals class
public class Globals {
[Bindable] public var iCollection:ArrayCollection;
}
It can be accessed from anywhere in the program (provided you have assigned a valid ArrayCollection to it first)
combobox.dataProvider=Globals.iCollection;
I don't understand why JSR 303 (bean validation) is for the getter methods and not setter? Isn't it more logical to put it under setter method since that is the entry point into a field and validation should be checked prior to that?
Annotating getters doesn't mean that validation is performed when a getter is invoked. It is just used to identify the property to which a constraint shall apply.
The big advantage of putting constraints on (usually public) getters instead on (typically private) fields is that the constraints are part of the type's public API that way. They will even be added to the generated JavaDoc. A user of a type knows that way which constraints apply to it without looking into its internal implementation.
Another advantage of annotating getters is that constraints can be put at methods on base classes or interfaces and also apply for any sub-types/implementations.
Its a very good question and something that I have never paid attention to. But I think I know the answer ( and also why I never got this question myself).
If you are looking at this, from the point of view that, the annotation defines where the validation will happen, then putting it on getter does not make sense. ( why not validate while storing the value itself..). But this is not how it works...
The programmer needs to tell the validation framework, which properties needs to be validated. So you can put the annotation directly on the attribute (which I prefer) or you can put it on the getter. Both of them signify read operation. The Framework needs to read all the attributes of your class, that will have to be validated. So in this case, putting on setter makes no sense at all.. The key to understand is the perspective...
I hope it makes sense.
Consider this code:
public class BeanValidation {
private int nameSetCount = 0;
private int nameGetCount = 0;
private String name;
public String getName() {
this.nameGetCount++;
return name;
}
public void setName(String name) {
this.nameSetCount++;
this.name = name;
}
}
Put annotation over private String name;
Annotation identifies field easily just looking at the field.
Put annotation over public String getName()
Annotation identifies field easily just looking at the returned field.
Put annotation over public void setName(String name)
Annotation can not identify field looking at the modified field because there can be more than one.
Bean Validation is called that way for a reason. It is applied to an initialized bean. So, first off, you initialize it with everything you have, then you pass it(or it is passed explicitly) to the Bean Validation implementation, which will rely on the validation annotations when accessing the fields.
In case of Spring MVC validation handling starts at:
result = execVal.validateParameters(
invocation.getThis(), methodToValidate, invocation.getArguments(), groups);
inside MethodValidationInterceptor. From here on, it's passed to validation implementation, in most cases Hibernate.
invocation.getArguments() will contain all the method arguments already initialized with the given values, regardless of validation annotations.
Why not getters? And how it combined with encapsulation principe? Does it safe?
Upd:
Yes, I'm about Request. Safety: I mean that anybody in code (by using listener) can do $request->attributes = null;
If you are talking about the Request and Response objects, there was a discussion about this on the Symfony developers mailing list a few days ago. I invite you to take a look at it here.
Why not getters? Not sure if there is a definitive answer to this but I think it is a decision based on personal tastes mainly.
Does it break encapsulation? Not really in my opinion for this particular case. My reasoning is that for now, no special logic is performed on the various objects that are public right now. So in the end, you would end up retrieving the object via a getter and read or modify it directly. There is not much difference with retrieving the object using a public property.
// With Getters
$parameterBag = $request->getQuery();
$parameterBag->get('key');
// With Public Properties
$parameterBag = $request->query;
$parameterBag->get('key');
Encapsulation should be enforced when you need to be sure that a property has a particular value or format. For example, say you have a class with a cost property and this property should never be negative. So if the cost property was public, it could be possible to set it to a negative value by doing something like $receipt->cost = -1;. However, if you make it private and the user of the class is only able to set it via a setter, then you could ensure that the cost is never below 0 by doing some special validation in the setter code.
In our case, we are talking about a collection object, a ParameterBag object to be precise. I don't think there are special requirements on this object but I could be wrong. So for me, it is correct to have access to those properties via public properties.
The main argument I could see in favor of the getters is that it would be more consistent with the other parts of the framework where getters are used. However, the getters could co-exist with the public properties.
To conclude, I think it is safe for this particular case. Public properties should be used only in special cases where it seems to be beneficial and where it is correct to do so.
Do you mean the Request object? Or what properties are you thinking of?
If you're worried about safety, then take a look at the Security component, use Test-Driven-Development, use tested libraries (don't invent your own authentication, cryptography and related solutions) and do code reviews.
What's the point to encapsulate what already's been encapsulated? I mean - each of this properties is a parameterBag instance with it's encapsulation.