Drools supports the usage of properties of Pojos using a simple name. For example Person(age==10) to match a Person instance that has a getAge() method returning 10.
My problem now is that I have to handle something that is not a pure Pojo and instead has a generic getter. So for the Person example above I need a transformation to Person(myGenericPropertyLookupMethod("age")==10). And I need this for all such property usages, which includes for example the usage of from and chaining like $street : String() from $person.address.street. where at least street must be looked up using myGenericPropertyLookupMethod.
Related
In my business logic I have to deal with a lot of entity IDs, all of them of type String, which can cause confusion especially when you pass a couple of them as method parameters. So I thought about introducing a little type safety with inline classes. I know, inline classes are still marked as experimental in v1.3. Nevertheless, has anyone ever tried to use an inline class as the #Id property within a DB mapping context, in my case a MongoDB with Spring Data.
#Entity
class User {
#Id
var id: UserId
}
with
inline class UserId(val id: String)
I guess there is no unboxing of the underlying property, so _id will end up as an object in the DB? And what about Spring's CrudRepository interfaces? It seems compilable but will it work eventually:
interface UserRepository : CrudRepository<User, UserId>
Probably using AttributeConverter to convert the inline class to a primitive might do the job. Any experiences with this?
Inline classes result in completely new types, not just a typed Alias. Even if our code base knows what this new type is the MongoDB doesn't right? So you cannot store the inline class directly into the corresponding primitive type Fields
There is an unresolved ticket for Spring Data Commons: https://github.com/spring-projects/spring-data-commons/issues/1947
Using Entity Framework, is IEnumerable the correct container to use to send back a generic data set? I.e. when I do not want to send back a list of the object, but just a generic a result set.
public IEnumerable<object> SelectPlayerFirstAndLastNameList()
{
return (from p in rlpEntities.Players select new { p.PlayerFirstName, p.PlayerLastName });
}
Thanks.
Here is the reference article, which talks about IList(inherits ICollection( and IEnumerable(Base Generic Interface for IQueryable,ICollection,List).
Here are the links which states generics & it's differences & it's usages,
Difference among IEnumerable , IQueryable, ICollection,IList, List
IEnumerable vs. ICollection vs. IQueryable vs. IList
Looking at your linq, it's about specific object & can be extended further in future. IQueryable is right fit for such scenario, as it gives client to iterate/add/remove items.
Check this link out Why use ICollection and not IEnumerable or List<T> on many-many/one-many relationships?.
It really depends on your scenario, but IEnumerable<> would be used when you need to iterate, and List<> when you need to iterate and modify or sort the data.
IEnunerable<> - http://msdn.microsoft.com/en-us/library/system.collections.ienumerable.aspx
List<> - http://msdn.microsoft.com/en-us/library/6sh2ey19.aspx
You can also use generics, to pass on whatever types you are querying against, like for instance
public IEnumerable<T> SelectPlayerFirstAndLastNameList<T>()
{
return (IEnumerable<T>)(from p in rlpEntities.Players);
}
So you can pass either object, or a known defined type. To call this you would do
var x = SelectPlayerFirstAndLastNameList<YourClassHere>();
I think what you have is correct but decide for yourself whether you should use it.
From MSDN: Anonymous Types in the Remarks section:
Anonymous types are class types that derive directly from object, and
that cannot be cast to any type except object.
and
To pass an anonymous type, or a collection that contains anonymous
types, as an argument to a method, you can declare the parameter as
type object. However, doing this defeats the purpose of strong typing.
If you must store query results or pass them outside the method
boundary, consider using an ordinary named struct or class instead of
an anonymous type.
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.
What is the philosophy behind making the instance variables public by default in Scala. Shouldn't making them private by default made developers make less mistakes and encourage composition?
First, you should know that when you write:
class Person( val name: String, val age: Int ) {
...
}
name and age aren't instance variables but accessors methods (getters), which are public by default.
If you write instead:
class Person( name: String, age: Int ) {
...
}
name and age are only instance variables, which are private as you can expect.
The philosophy of Scala is to prefer immutable instance variables, then having public accessors methods is no more a problem.
Private encourages monoliths. As soon as it's easier to put unrelated functionality into a class just because it needs to read some variables that happen to be private, classes start to grow.
It's just a bad default and one of the big reasons for classes with more than 1000 lines in Java.
Scala defaults to immutable, which removes a massive class of errors that people often use private to restrict (but not remove, as the class' own methods can still mutate the variables) in Java.
with immutables which are preferred in many places, public isn't so much of an problem
you can replace a public val with getters and setters without changing the client code, therefore you don't need the extra layer of getters and setters just in case you need it. (Actually you do get that layer but you don't notice it most of the time.)
the java anti pattern of private field + public setters and getters doesn't encapsulate much anyway
(An additional view supplementing the other answers:)
One major driver behind Java's encapsulation of fields was the uniform access policy, i.e. you didn't have to know or care whether something was implemented simply as a field, or calculated by a method on the fly. The big upside of this being that the maintainer of the class in question could switch between the two as required, without needing other classes to be modified.
In Java, this required that everything was accessed via a method, in order to provide the syntactic flexibility to calculate a value if needed.
In Scala, methods and fields can be accessed via equivalent syntax - so if you have a simple property now, there's no loss in encapsulation to expose it directly, since you can choose to expose it as a no-arg method later without your callers needing to know anything about the change.
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.