JXA’s Parenthesis Paradox | Hacker News Reader

JXA’s Parenthesis Paradox

leancrew.com

27 pointsarm6 comments

This really clicked for me in Javascript when revisiting the saying "functions are first-class objects in JS".

I think most people know this in the context of callbacks or lambdas, but it's useful to keep in mind that this is how all functions in JS work: A function is an object with support for a special "call" operation and () is an operator that invokes that operation on whatever object is given.

So Application('System Events').processes() is invoking "call" on the object contained in the "processes" property.

But because it's an object, it also supports all the other operations of objects, such as attaching properties - which can contain other callable objects.

So Application('System Events').processes.name() is fetching the "name" property of the same object and invoking "call" on that value.

In other words, it has syntactic sugar for lifting a projection into the list functor. Aka fmap.

Also, the "x of every y whose z is w" is a list comprehension :)

I really wish Apple made JXA easy to write and debug with proper documentation.

I know JS very well, but it takes me 20x longer than web stuff to workout how to do something as it’s just pure trial and error.

Each script run is slow as it must actually do the actions in the GUI.

JS is more useful than AppleScript in my opinion as it supports JSON data and functions.

Looks like JXA offers properties and methods, with parallel namespaces.

properties like `foo` are objects with rich API of methods and properties

methods like `foo()` give a data serialization

I think this comes down to how apple events (the underlying mechanism used for applescript) works internally, which is basically rpc + relational queries. The only good documentation I've found on how this works is at [1]

>In order to use appscript effectively, you will need to understand the differences between the Apple event and Python object systems.

>In contrast to the familiar object-oriented approach of other inter-process communication systems such as COM and Distributed Objects, Apple event IPC is based on a combination of remote procedure calls and first-class queries - somewhat analogous to using XPath over XML-RPC.

I think the developer of appscript has posted about this on HN a few times in the past.

Btw the article's example is the following in py-appscript:

   app('System Events').processes[(its.visible == True).AND(its.name.beginswith('M'))].name.get()

Although even this might be a bit misleading since the array access isn't actually accessing any array but from what I understand is just syntactic sugar to build up the query (the apple-event equivalent of a DOM selector or xpath). Or maybe if it's easier you can treat it as lazy evaluation, until the actual .get() fires the rpc

[1] http://appscript.sourceforge.net/py-appscript/doc_3x/appscri...

I’m thinking with a little tomfoolery you could get the python version to mimic the parentheses paradox without having to overload the array access operator. I’d have to think about how much the call order would matter and how much hackery it would take if it did. I think it could be made to work by abusing the attribute lookup function, I did something similar in a project but it didn’t pass information from the general to specific (if that’s even required for this).

The real question is if you’d want to as it wouldn’t be very pythonic.

Reply on news.ycombinator.com