ECMAScript target version

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

ECMAScript target version

Tom Scavo
Until recently I didn't know much about the various scripting engines
(Rhino, Nashorn, GraalVM, etc.) and how well they support the
ECMAScript standard. After doing some research on the subject, I've
concluded that the target version for sample scripts should be
ECMAScript 5.1, so I'll stick to that as best I can. This is rather
inconvenient since ECMAScript 2015 (aka ECMAScript 6) is near
universal AFAICT.

In any case, I documented suggested best coding practices in the
ScriptTypeConfiguration [1] topic. I tried to stay away from
contentious issues (involving [2], e.g.) but if you could review and
comment on what I wrote in the wiki, I'd appreciate it.

Thanks,

Tom

[1] ScriptTypeConfiguration  https://wiki.shibboleth.net/confluence/x/iQAOAg
[2] https://issues.shibboleth.net/jira/browse/JPAR-121
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: ECMAScript target version

Rod Widdowson
My immediate reaction is that it is out of scope for us to be telling any of our customer how to write scripts, and in particular
what language they should use.

We should go for the lowest common denominator in our example (so if something will work in rhino and Nashorn that is what we should
ship).  Further I think that we need to have the simplest possible code in our examples.  So the extra levekl of function
indirection that a lot of the samples currently have is just confusing for people who are not programmers and must want to get a job
done.  So we might know that

(funcrtion(foo, custom, prc){return false;} (input, custom, prc);

Is the same as

false;

but it is far more interesting to our end users that they see the latter.

R

> -----Original Message-----
> From: dev [mailto:[hidden email]] On Behalf Of Tom Scavo
> Sent: 24 July 2018 13:03
> To: Shibboleth Developers <[hidden email]>
> Subject: ECMAScript target version
>
> Until recently I didn't know much about the various scripting engines (Rhino, Nashorn, GraalVM, etc.) and how well they support
the
> ECMAScript standard. After doing some research on the subject, I've concluded that the target version for sample scripts should be
> ECMAScript 5.1, so I'll stick to that as best I can. This is rather inconvenient since ECMAScript 2015 (aka ECMAScript 6) is near
universal

> AFAICT.
>
> In any case, I documented suggested best coding practices in the ScriptTypeConfiguration [1] topic. I tried to stay away from
> contentious issues (involving [2], e.g.) but if you could review and comment on what I wrote in the wiki, I'd appreciate it.
>
> Thanks,
>
> Tom
>
> [1] ScriptTypeConfiguration  https://wiki.shibboleth.net/confluence/x/iQAOAg
> [2] https://issues.shibboleth.net/jira/browse/JPAR-121
> --
> To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: ECMAScript target version

Cantor, Scott E.
> We should go for the lowest common denominator in our example (so if
> something will work in rhino and Nashorn that is what we should ship).

Unfortunately those two are fairly different in practice, so beyond simple examples it's common to have to pick one, and I've stuck with Nashorn since that is the official Java implementation now. And given that it will probably be 2021 at the earliest before that changes, it's not an urgent thing to deal with it changing, we just have to keep an eye out.

> Further I think that we need to have the simplest possible code in our
> examples.  So the extra levekl of function indirection that a lot of the samples
> currently have is just confusing for people who are not programmers and
> must want to get a job done.  So we might know that
>
> (funcrtion(foo, custom, prc){return false;} (input, custom, prc);
>
> Is the same as
>
> false;
>
> but it is far more interesting to our end users that they see the latter.

+1, these are, by and large, already just simple function calls, so that indirection doesn't really add anything useful unless the example is so advanced that there's a portion that needs to be factored. I don't mind an example or two showing it, but they shouldn't routinely.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ECMAScript target version

Tom Scavo
Thanks for the feedback. That saves me a lot of time. For now, I’ll
just leave things as they are. Feel free to jump in and change the
docs to suit your taste.

That said, here’s my two cents. The function indirection has at least
three advantages: 1) it permits the use of the return statement; 2) it
introduces formal parameters with meaningful names; and 3) it aligns
with the definition of Guava Functions and Predicates.

Btw, Guava is mostly redundant at this point due to the introduction
of the java.util.function package in Java 8, but the two approaches
are similar in spirit, so I guess it doesn’t matter.

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ECMAScript target version

Cantor, Scott E.
On 7/25/18, 3:04 PM, "dev on behalf of Tom Scavo" <[hidden email] on behalf of [hidden email]> wrote:

> Btw, Guava is mostly redundant at this point due to the introduction
> of the java.util.function package in Java 8, but the two approaches
> are similar in spirit, so I guess it doesn’t matter.

The IdP is built with Java 7, not 8.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]