Javaslang object does not work

Question

I am using Javaslang-2.1.0-alpha and its equivalent Javaslang, equivalent to decomposing some objects. According to this blog post posted by Daniel in the “Match the Fancy way” section:

Match(person).of( Case(Person("Carl", Address($(), $())), (street, number) -> ...) ) 

You need to get the values ​​that match the two lookup patterns inside Address , in street and number , but this example does not even compile. Later, I realized that all objects should be wrapped inside atomic patterns, i.e. "Carl" becomes $ ("Carl"). This was after reading this issue .

I followed the updated tutorial , but there was no update in this example.

I updated the example:

 Person person = new Person("Carl", new Address("Milkyway", 42)); String result2 = Match(person).of( Case(Person($("Carl"), Address($(),$())), (street, number) -> "Carl lives in " + street + " " + number), Case($(), () -> "not found") ); System.out.println(result2); 

It compiles, but my values ​​do not match properly, judging by the console output:

 Carl lives in Carl Address [street=Milkyway, number=42] 

Clearly, street contains Carl and number , the entire Address object.

When I try to add a third lambda parameter to catch Carl :

  Case(Person($("Carl"), Address($(),$())), (name, street, number) -> "Carl lives in " + street + " " + number) 

The code cannot compile, the lambda expression gets a red underline with the following error text:

 The target type of this expression must be a functional interface 

In recent versions of javaslang-match there is no way to ignore the value with $_ . Therefore, I want to map every atomic pattern that will return three lambda parameters, as indicated above.

I need someone who understands this library to explain to me how to make this decomposition of an object in the latest version.

Answer 1

Disclaimer: I am the creator of Javaslang.

Case must be processed (String, Address) → {...}. $ () Corresponds to arbitrary values, but the handler / function receives only the first layer of the tree of broken objects. $ () Are on the second level.

Rule: all layers are mapped to templates, only the first level is passed to the handler.

The first Match prototype actually handled arbitrary tree depths, but the methods that should be generated under the hood for all possible combinations are the maximum size of the byte code, and compilation time has exploded exponentially.

The current version of Match is the only practical Java way that I see at the moment.

Update:

Please give me a more imaginative update on this topic.

We distinguish

• Input Object Chart
• Template tree transmitted in case of compliance
• decomposed objects graph objects

Announcement 1) Schedule of objects

When defining an object, the graph of the object is stretched by moving the properties (respectively, instance variables) of this object. In particular, we do not prohibit an object from containing loops (for example, a mutable list that contains itself).

There is no natural way to decompose an object into its parts in Javaslang. For this purpose, we need a so-called template.

Example plot of an object:

  Person <-- root / \ "Carl" Address <-- 1st level / \ "Milkyway" 42 <-- 2nd level 

Announcement 2) Template Tree

A sample (instance) essentially determines how to decompose an object.

In our example, the template types look like this (simplified generics):

  Pattern2<Person, String, Address<String, Integer>> / \ Pattern0<String> Pattern2<Address, String, Integer> / \ Pattern0<String> Pattern0<Integer> 

The called template methods return instances of the above types:

  Person(...) / \ $("Carl") Address(...) / \ $() $() 

The Javaslang Compliance API does the following:

• The Match instance passes the given person object in the first case.
• The case passes the person object to the Person(...) template Person(...)
• The Person(...) template Person(...) checks to see if the given person object is of type person .
  • If true, the template decomposes the object into parts (represented by a tuple) and checks if the $("Carl") and Address(...) submatrices match these parts (repeats 3. recursively)
  • If false, then Match passes the object to the next Case (see 2.)
  • If the pattern is atomic, i.e. he can no longer decompose the object, then equality is checked and the callers are reported back in case of compliance.
• When the match case has received a match for the pattern , it passes the decomposed objects of the first level of the feature graph to the case matching handler.

Currently, the Java-type system does not allow the transfer of consistent objects of an arbitrary level of an object / tree in a typed form to a handler.

Ad 3) Split Objects

We have already mentioned the decomposition of objects above in 2). In particular, it is used when parts of our data are sent through the template tree.

Due to the limitations of the type system mentioned above, we separate the process of matching an object with the processing of decomposed parts.

Java allows us to map arbitrary graphs of objects. We are not limited to any level here.

However, when the object is successfully mapped, we can only pass the processed objects of the first layer to the handler.

In our example, these are the expanded objects of the name and address given person (and not street and number ).

---

I know that this is not obvious to the user of the compliance API.

One of the next versions of Java will contain value objects and their own pattern matching! However, this version of pattern matching will be completely limited to level one.

Javaslang allows you to map arbitrary graphs of objects, but it has a price. The handler really only gets the first layer of decomposed objects, which can be misleading.

I hope this answers the question in an understandable way.

- Daniel