It appears BeanIO requires I provide setters for my fields. Is this necessary? I created a BeanIO writer, I intend only to write files, and I have getters for each field - why would I need setters?
If your beans are only meant to be serialized (i.e. used by a BeanWriter), you can declare your stream as mode="write". This will cause BeanIO to look for getters but not setters.
The reference guide states that:
By default, a stream mapping can be used for both reading input streams and writing output streams, called readwrite mode. Setting mode to read orwrite instead, respectively restricts usage to a BeanReader or a BeanWriter only, but relaxes some validations on the mapping configuration.
When mode is set to read, a bean class does not require getter methods.
When mode is set to write, a bean class may be abstract or an interface, and does not require setter methods.
Related
Was reading about JPA here. Two of the requirements of an Entity class are that
The class must not be declared final. No methods or persistent instance variables must be declared final.
The class must have a public or protected, no-argument constructor.
Persistent instance variables must be declared private, protected, or package-private.
Was curious to know why are these conditions required ?
The class must not be declared final. No methods or persistent instance variables must be declared final.
JPA implementations use proxies in front of your entities to manage for example: Lazy loading. As a final class cannot be extended, a proxy cannot be built.
Some implementations as Hibernate can persist final classes but it can affect performance more info.
The class must have a public or protected, no-argument constructor.
These kind of frameworks and others in order to create new objects use ```Class.newInstance()`` that is the reason why a no arg constructor is needed.
Persistent instance variables must be declared private, protected, or package-private.
Being only accesible through accessor or business methods allow interception in proxies.
The reasons are (at least some of them):
JPA provider needs to create instances of the entity dynamically. If class would contain the only constructor which takes arbitrary arguments, JPA provider cannot figure out values for those arguments. That's why it must has a no-arg constructor.
JPA implementations deal with persisting instances of your entities classes. that's why the class, methods and variables cannot be final.
Because you don't want access to the variables from outside directly, in order to keep encapsulation - this is an OOP reason. another reason is that many frameworks of persistence are having a getter/setter method to identify POJO "properties".
I have a classe derived from matlab.mixin.Copyable. Some of the properties have set methods. I want the setting of those properties to also update other properties so that the relationship between the parameters are consistent (a classic use of set methods).
Unfortunately, when I load a *.mat file [specifically using, say, x=load('file.mat')], setters are also used. There should be no need for that kind of automatic update of multiple parameters, since all the object's properties can be copied from the *.mat file and self-consistency is automatically maintained. Instead, using setters during load causes errors because the setter uses other properties that haven't yet been assigned to in the load process. I see this from error that occurs during the load, and from checking the properties that are needed by the setter.
Is there any way to force the load to do a simple replication of the property values contained the *.mat file? Some of the properties are complex objects themselves, so what's needed is a recursive copy-by-value during load. It seems rather inappropriate to use setters during a load, for the reasons above.
P.S. I say above that the setter uses another as-yet-unassigned property. Let's call this property p2. It also gets assigned to by a setter for 3rd property s1. It seemed odd, but s1 does have a value, while p2 does not. One possible reason is that p2 relies on other properties in addition to s1, and those might not have been assigned to when s1 is loaded (i.e., when the s1 setter is invoked). The whole problem stems from the fact that load occurs outside of the context and the order in which properties are assigned to during the execution of the code that created it. This is the key reason why (it seems to me that) load should not use setters. Otherwise, it seems to be incompatible with either copying or loading (I'm not sure which at the moment -- maybe both).
The process MATLAB uses to load objects is well documented. This page mentions, among many other things, that the set methods are called to prevent issues that happen when a class definition changes, and you try to load an object from that class from an old file.
There is also a page explaining how to modify the save and load process. This page describes the use of loadobj, defined as a static method to your class, to change how the object is constructed from the information in the file. loadobj is called when one of the set methods throws an error; but it is always called if saveobj returns a struct. That is, one solution to your problem is to have saveobj create a struct with all the data, and have loadobj reconstruct your object from that struct.
This other documentation page describes how to design your class to avoid property initialization order dependency -- which is the problem you describe having. The way to do this is to have all public properties be dependent properties, with the "actual" data properties being hidden and not interdependent. You might be able to construct your class this way, for example with a single data property (a cell array or struct), which would be loaded and saved in one go, and the public properties simply using a portion of this cell or struct in the set and get methods.
In swift, how is constants implemented?
I read this article, which says
In Swift, constants are generally implemented as (inlined) function calls.
I am not clear of this statement.
Does Swift use a special approach to make constants?
Could anyone explain?
Are you familiar with "getter" and "setter" methods from other languages, such as Java? If a variable is made public in a language like Java, it's exposed to other classes to access directly. In the future, if this variable has to be changed, there's no way to do so without changing all of the other classes dependent upon. With getter/setter methods, dummy implementations can be made that don't do anything besides read/write the value. In the case that a change needs to be made, the implementation of these methods can be changed without effecting the public API of the class.
Swift implements variables with "properties", which are like a backing private variable with public getter/setter methods that are automatically generated. In the future, you can replace a property with a computer property with a special getter/setter implementation, without effecting the public API of the class, just like before. The difference here is that you don't need to write all of the default getters/setters yourself.
I have a third-party library which is written in Swift. The library provides a class that has some class methods in it. Using Typhoon, I want to inject the class into one of my classes so that, under unit testing, I could inject a mock class that provides fake class methods. I'm new to Typhoon and I went though the documentation, but haven't figured out how to do it. Is this even doable with Typhoon?
Yes, in the User Guide the section on Injecting Configuration shows how to inject primitives, scalar values and so forth.
To inject a class:
[initializer injectParameterWith:[SomeClass class]];
This also applies to property injection and method injection.
To inject a selector:
[initializer injectParameterWith:NSValueFromPrimitive(#selector(selectorValue))];
Typhoon rules:
References to other definitions are resolved to the built instance.
Simple objects, primitives and scalar values are injected as-is (scalar values and primitives must be wrapped).
Collections (NSArray, NSSet, etc) that contain references to other definitions have those references resolved to the built instance. Any other values pass through as is.
There is also Typhoon Config, which allows storing configuration, simple objects and so forth in an external plist, json or properties file.
According to the JPA 2.1 spec:
It is required that the entity class follow the method signature
conventions for JavaBeans read/write properties
(as defined by the JavaBeans Introspector class)
for persistent properties when property access is used.
In this case, for every persistent property property of type T
of the entity, there is a getter method, getProperty,
and setter method setProperty.
Does this imply that the methods must always be named getProperty
and setProperty
(per the design pattern "convention" in ยง8.3.1 of JavaBeans spec 1.0.1,
"[i]f we don't find explicit BeanInfo on a class");
or could a BeanInfo class be provided to direct the JPA implementation
to a different method
(per the full description of the Introspector class in that spec)?
Although I'm also curious about how Hibernate or other JPA implementations
implement this,
I'm instead really asking what implementation the JPA spec requires.
The methods MUST be named as per the Java Beans contract ... getXXX (or isXXX), setXXX. There is no BeanInfo hook used by any JPA implementation I know of