Ha Ha, Paulo Moura called my first example code
smelly. The only smelly thing was his light
yellow scrennshot, which looked like piss.
If you compare two solutions, that use the
same setter and getter granularity, also if
the setter and getter don't do much, you are
comparing apples with apples. With was my
first test case, I only used =... for the
setter, which turned out to
be a speed brake for SWI-Prolog. But there is
nothing wrong with that. In Java and other
programming languages, you often code setters
and getters, even if they don't do a lot. You
do this for various reasons:
- You can use the visibility modifiers of the setters and
getters to regulate what can go out and in of an object.
- This probably doesn't completely translate to parametric
objects, which have their equivalent in Java and Scala
as so called value objects. Usually value objects are
immutable, so they don't have usually setters.
- But by using the name with/n to make a copy (in your case
for a parametric object and not a map), you are in
good company, this is found for example in Erlang:
with(Ks, Map1) -> Map2
http://erlang.org/doc/man/maps.html
- In usually OO-programming, some setters or getters
might exists, so that subclasses override them. We
might even see example code, where some setters
and getters are declared abstract or from an interface.
- The later is no so much required for Prolog VM,
since the dynamic dispatch doesn't need types. But
we would need bigger test examples to test that.
Theoretically I can call anything anytime with any
method I desire. This is even more powerful than
duck typing as found in the Go programming language.
What I am planning to do more on testing, is to test the
colorpoint problem against Java and Scala. Testing against
Scala is especially interesting, since they have pattern
matching, which is in competition with Prolog rules.
Writing a similar value object based code for Java and
Scala could give empirical results what is theoretical
possible, and found at the formost front of virtual methods.
One could of course also try C++ or Python variants
and compare. This would probably give a lower bound
on what a Prolog VM can practically reach in the future,
concering the ISO module required dispatch.
Am Donnerstag, 21. Juni 2018 20:06:27 UTC+2 schrieb
burs...@gmail.com: