I am trying to implement a custom control (I call it DataGrid) , which I choose to derive from Selector. In cppwinrt , I write some like this
struct DataGrid : SelectorT<DataGrid>
{
}
This code does not compile. In fact , there is no such a struct called SelectorT in any of the shipped Windows.UI.Xaml.Controls.Primitives.h files. I've checked the winmd file shipped with the SDK (19041) , found that Selector is Composable (has the ComposableAttribute attribute), so, SelectorT should have been generated , what I've missed ? Many thanks!
There is no SelectorT because Selector can not be subclassed. The TypenameT class templates in the consuming projection are not provided for convenience, they exist to provide user-defined subclasses of Xaml types that support it. This allows the user to define their own implementations of overrideable methods. (Think of it as similar to C++ virtual functions, but in a complicated COM aggregation way)
The docs don't appear to spell out in clear words which classes can be subclassed, and which ones can't. You can deduce this, though, from the presence of ComposableAttribute on the type, as in FrameworkElement.
Related
This question is for JVM specification advocates. According to the JVMS, Java SE 7 edition, section 5.3.3, last paragraph:
If the component type is a reference type, the accessibility of the array class is determined by the accessibility of its component type. Otherwise, the accessibility of the array class is public.
Thus an array class can have package visibility. Logically I would expect that, if foo.baz.MyClass has package visibility, then an array of MyClass is visible only to package foo.baz. But I can't find anything in the specification supporting this view. Section 5.3 says that the run-time package, that should be used to determine visibility constraints, is built of the binary name of the package plus the defining classloader. But the binary name comes from the classfile, and array classes do not have classfiles. Similar issue for the primitive classes (e.g., Boolean.TYPE), which apparently have public visibility, but I cannot find information about them anywhere.
Can you spot a point in the JVMS where the package of array/primitive classes is clearly defined (or a reason why there is none)?
Isn't that exactly what the quote from the specification is saying?
If the component type is a reference type, the accessibility of the array class is determined by the accessibility of its component type.
If you have a class some.pkg.SomeClass and want to use it as some.pkg.SomeClass[] the accessibility is determined by the accessibility of its component type. In this case the component type is some.pkg.SomeClass.
The other case is for native types, and you can't add more native types to Java.
I have two frameworks in my Xcode project that both define a class with the same name (B.framework and C.framework both have a class named MyClass), resulting in a couple warnings like so:
Duplicate symbol _OBJC_METACLASS_$_MyClass originally in B.framework/B(MyClass.o) now lazily loaded from C.framework/C(MyClass.o)
Duplicate symbol _OBJC_CLASS_$_MyClass originally in B.framework/B(MyClass.o) now lazily loaded from C.framework/C(MyClass.o)
Then at run time only one of the implementations is loaded, and trying to use the other one will result in a "unrecognized selector sent to instance" because they are totally different classes (even though they have the same name).
I use one of the MyClass implementations directly in my code, but the other framework only uses its MyClass internally and I have no idea why its even exported (its not even mentioned in the frameworks header files, i used nm to view the symbols).
How can I make both frameworks work?
There's no such thing as "exported" classes in Obj-C. Or rather, there's no such thing as "non-exported" classes. This problem is precisely why the use of 2- or 3-letter prefixes on classes is strongly recommended for all Obj-C code. Your only solution (besides not using these frameworks) is to edit one (or both) of the frameworks to change the class name, or if you don't have access to the source, then you need to contact the vendor and ask them to make that change.
I have a Struts 1 application which works with Velocity as a template language. I shall replace Velocity with Freemarker, and am looking for something similar to 'toolbox.xml'-File from VelocityViewServlet. (there you can map names to Java Classes and, using these names it is possible to access methods and variables of various Java class in the Velocity template).
Does someone know, what is possible with Freemarker instead? So far I have found only information about the form beans...would be glad if someone can help....
For the utility functions and macros that are View-related (not Model-related), the standard practice is to implement them in FreeMarker and put them into one or more templates and #import (or #include) them. It's also possible to pull in TemplateDirectiveModel-s and TemplateMethodModelEx-es (these are similar to macros and function, but they are implemented in Java) into the template that you will #import/#inlcude as <#assign foo = 'com.example.Foo'?new()>.
As of calling plain static Java methods, you may use the ObjectWrapper's getStaticModels() (assuming it's a BeansWrapper subclass) and then get the required methods as TemplateMethodModelEx-es with staticModels.get("com.example.MyStatics"). Now that you have them, you can put them into the data-model (Velocity context) in the Controller, or pick methods from them in an #import-ed template, etc. Of course, you can also put POJO objects into the data-model so you can call their non-static methods.
The third method, which is not much different from putting things into the data-model is using "shared variables", which are variables (possibly including TemplateMethodModelEx-es and TemplateDirectiveModel-s) defined on the Configuration level.
This question already has answers here:
What is reflection and why is it useful?
(23 answers)
Closed 6 years ago.
I was just curious, why should we use reflection in the first place?
// Without reflection
Foo foo = new Foo();
foo.hello();
// With reflection
Class cls = Class.forName("Foo");
Object foo = cls.newInstance();
Method method = cls.getMethod("hello", null);
method.invoke(foo, null);
We can simply create an object and call the class's method, but why do the same using forName, newInstance and getMthod functions?
To make everything dynamic?
Simply put: because sometimes you don't know either the "Foo" or "hello" parts at compile time.
The vast majority of the time you do know this, so it's not worth using reflection. Just occasionally, however, you don't - and at that point, reflection is all you can turn to.
As an example, protocol buffers allows you to generate code which either contains full statically-typed code for reading and writing messages, or it generates just enough so that the rest can be done by reflection: in the reflection case, the load/save code has to get and set properties via reflection - it knows the names of the properties involved due to the message descriptor. This is much (much) slower but results in considerably less code being generated.
Another example would be dependency injection, where the names of the types used for the dependencies are often provided in configuration files: the DI framework then has to use reflection to construct all the components involved, finding constructors and/or properties along the way.
It is used whenever you (=your method/your class) doesn't know at compile time the type should instantiate or the method it should invoke.
Also, many frameworks use reflection to analyze and use your objects. For example:
hibernate/nhibernate (and any object-relational mapper) use reflection to inspect all the properties of your classes so that it is able to update them or use them when executing database operations
you may want to make it configurable which method of a user-defined class is executed by default by your application. The configured value is String, and you can get the target class, get the method that has the configured name, and invoke it, without knowing it at compile time.
parsing annotations is done by reflection
A typical usage is a plug-in mechanism, which supports classes (usually implementations of interfaces) that are unknown at compile time.
You can use reflection for automating any process that could usefully use a list of the object's methods and/or properties. If you've ever spent time writing code that does roughly the same thing on each of an object's fields in turn -- the obvious way of saving and loading data often works like that -- then that's something reflection could do for you automatically.
The most common applications are probably these three:
Serialization (see, e.g., .NET's XmlSerializer)
Generation of widgets for editing objects' properties (e.g., Xcode's Interface Builder, .NET's dialog designer)
Factories that create objects with arbitrary dependencies by examining the classes for constructors and supplying suitable objects on creation (e.g., any dependency injection framework)
Using reflection, you can very easily write configurations that detail methods/fields in text, and the framework using these can read a text description of the field and find the real corresponding field.
e.g. JXPath allows you to navigate objects like this:
//company[#name='Sun']/address
so JXPath will look for a method getCompany() (corresponding to company), a field in that called name etc.
You'll find this in lots of frameworks in Java e.g. JavaBeans, Spring etc.
It's useful for things like serialization and object-relational mapping. You can write a generic function to serialize an object by using reflection to get all of an object's properties. In C++, you'd have to write a separate function for every class.
I have used it in some validation classes before, where I passed a large, complex data structure in the constructor and then ran a zillion (couple hundred really) methods to check the validity of the data. All of my validation methods were private and returned booleans so I made one "validate" method you could call which used reflection to invoke all the private methods in the class than returned booleans.
This made the validate method more concise (didn't need to enumerate each little method) and garuanteed all the methods were being run (e.g. someone writes a new validation rule and forgets to call it in the main method).
After changing to use reflection I didn't notice any meaningful loss in performance, and the code was easier to maintain.
in addition to Jons answer, another usage is to be able to "dip your toe in the water" to test if a given facility is present in the JVM.
Under OS X a java application looks nicer if some Apple-provided classes are called. The easiest way to test if these classes are present, is to test with reflection first
some times you need to create a object of class on fly or from some other place not a java code (e.g jsp). at that time reflection is useful.
What is the standard way of incorporating helper/utility functions in Obj-C classes?
I.e. General purpose functions which are used throughout the application and called by more than 1 class.
Can an Obj-C method exist outside of a class, or does it need to be a C function for it to have this kind of behaviour?
I would group similar functions as static methods in a helper class. These can then be called using the classname rather the instance name. Static methods are defined with a + instead of the usual -.
like so:
#interface HelperClass: superclassname {
// instance variables - none if all methods are static.
}
+ (void) helperMethod: (int) parameter_varName;
#end
This would be called like so.
[HelperClass helperMethod: 10 ];
As this is static you do not init/alloc the class. This has the advantage of clearly grouping like Helper functions. You could use standalone C functions but as your Application gets larger it can become a right mess! Hope this helps.
Tony
I don't see why people are avoiding creating functions. Objective-C is a superset of C, which means that C is part of it. Moreover, it's completely integrated—there's no wall between them.
Create functions! It's fine! Foundation does it. Application Kit does it. Core Animation does it. Core Media does it.
I see no reason not to.
There are a number of options for this in Objective-C. First, since Obj-C is a strict superset of C, you can define all your library functions in a separate module (source file) and happily call them from any Obj-C object/code you already have. If you create an obj-c source file (.m file) you can then call back into/use objects.
If your generic functions are logically manipulating other, established objects (for instances, operates on an NSString), you can use categories to graph your functions on already existing classes (where that makes sense).
Finally, as Tony points out, you can create classes with static methods (although I like this option the least, personally). I tend to use a mix of one an two... adding categories where appropriate and using standard functions for others. I generally only make a new class where it makes sense to design a class.