[Scala] How does the check syntax work?

[Tomasz Grzejszczyk]

Hi everyone,

This is a type of "help me, I am new to Scala!" question.

It is baffling for me how do the checks like below even compile.

jsonPath("foo").saveAs("indices")

jsonPath("foo").find.saveAs("indices")

jsonPath("foo").find.transform(_.toUpperCase).saveAs("var")

jsonPath returns a MultipleFindCheckBuilder

.find and .transform return a ValidatorCheckBuilder

None of these traits implement a .saveAs method which is defined on a CheckBuilder trait. Even though the two above traits are named after a "CheckBuilder" they don't actually extend that trait in the code.

So how come does the compiler not complain? It is beyond me.

I can see here:
https://gatling.io/docs/gatling/reference/3.6/http/check/#validating that

> In the case where no verifying step is defined, a exists is added implicitly.

.exists actually returns a CheckBuilder object which does implement .saveAs, that is nice. Yes, but how does the compiler know that it should be "automatically" adding .exists here?

Regards,

Tomasz

[Stéphane LANDELLE]

Do you want to learn how those things work to become a Scala developer? As a Gatling user, this is an implementation detail.

Also, are you aware that Gatling 3.7 has a Java DSL too? It would probably be easier to understand (oh the boilerplate to implement it compared to Scala...).

--

Stéphane Landelle Chief Technical Officer

slan...@gatling.io gatling.io

   

--
You received this message because you are subscribed to the Google Groups "Gatling User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gatling+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gatling/989df5c5-5593-49a3-aaa5-381d4d5d7dd4n%40googlegroups.com.

[Tomasz Grzejszczyk]

Hi Stéphane,

>  Also, are you aware that Gatling 3.7 has a Java DSL too? It would probably be easier to understand (oh the boilerplate to implement it compared to Scala...)

I found out this week and I told the Tech Leads in my project about it. Java DSL is definitely a great selling point.

We are however currently using Gatling 3.6 and if and when we are going to upgrade to 3.7 remains to be seen.

It might also be that in this particular project we are stuck with Scala.

We have actually created a layer on top of Gatling that allows people with very little Gatling and Scala knowledge to create simple tests.

This works out pretty well unless it doesn't :-). Until this week our tests only needed to do very simple and always mandatory extractions.

Now I am extending our wrappers to also allow for optional checks and this is how I started looking at the relevant check APIs.

So this is the context of my question. I think I will be able to do what I need even not knowing what happens under the hood.

Being new to Scala I thought I could ask about the observed "magic" out of personal interest.

Regards,

Tomasz

[Sébastien BREVET]

Hello,

Being new to Scala I thought I could ask about the observed “magic” out of personal interest.

This “magic” comes basically from implicit conversion.

When the compiler does not find direct implementation (either an attribute or a method) in the type of the variable, it checks if there are implicit conversions in the scope that can be applied to the current variable that satisfies the requested name (attribute or method).

Terminology:

• conversion: a function that takes one parameter (with a defined type) and results in another type. sample: Integer.parseInt(str: String): Int (conversion from String to Int)
• implicit: a keyword and an “authorization” to the compiler to apply this object (value or method) when direct calls are not available

To put such implicit conversions in scope, we required you to import io.gatling.core.Predef._, so, everything in Predef (and its ancestor) is imported in scope.

For the specific case you mention:

• ValidatorCheckBuilder implements CheckBuilder.Validate (a Validate trait declared in CheckBuilder object)
• As you saw, they don’t define a saveAs method
• The compiler look in implicit conversions available in scope
• Among other things: io.gatling.core.Predef extends CoreDsl that itself extends CheckSupport
• You imported everything in Predef
• The compiler can apply the validate2Final implicit conversion to obtain a CheckBuilder.Final that implements the saveAs method

For more about implicit conversions:

• Scala tour
• Baeldung article

But all of these explanations are way beyond the purpose of this mailing list.

Hope that helps to understand,

Cheers!

To view this discussion on the web visit https://groups.google.com/d/msgid/gatling/8ad6cf0d-ffcf-4e17-ae9a-61110c7a851fn%40googlegroups.com.

--

Sébastien BREVET Backend engineer

sbr...@gatling.io gatling.io

[Tomasz Grzejszczyk]

Hi Sébastien,

Wow, your answer is way more detailed and way more precise than what I actually hoped for, thank you for that.

I would normally search for the articles on the 'implicit conversion' myself, but that is just difficult not knowing that such a thing exists.

Now I know why some code in my project compiles (which gives me a nice warm feeling inside)!

Regards,

Tomasz G.