3 ms·

Consider, (in my own syntax), on(table) select(blah) where(blah) groupby(blah) this is basically just, table.select(blah).whe

Consider, (in my own syntax), on(table) select(blah) where(blah) groupby(blah) this is basically just, table.select(blah).where(blah).groupby(blah) but this becomes inflexible when we want `table` to track more than just itself: table.connect().select(blah).where(blah).groupby(blah) suddenly, `table` holds fields which function like your "global variables". instead, on(table, connection) select() ... In otherwords OO already has this implicit mechanism at work in a highly action-at-a-distance manner, with unweildy objects functioning like a box-of-globals. By being explicit about which "nonlocal"s are required for an API, we can control this better. And also compose-in other APIs, etc., add toJson() at the end. (NB. nonlocal in the sense that they are common to most/all uses of an API) Python does this with decorators, but if it would add a little function chaining/compositon syntax, it would be more powerful.

derriz 4y ago
Yes, you can achieve also reduce local readability by passing objects containing buckets of state around. But such classes always smell to me - particularly if component instances have other aliases. But I try to avoid it by designing distinct and hopefully coherent service or context classes. And this Kotlin feature effectively requires you structure your context/service/etc. classes in this way - the point is to allow multiple implicit contexts. When you say 'action-at-a-distance' - I would argue that the "distance" is not on the same scale. One crosses statements invisibly while your example, in all languages I've used, would still constitute a single statement. But fundamentally, this is an argument about style as it's not a pure binary distinction, so I don't think there's a definitive right or wrong here. Subjectively - in my experience, codebases (remembering one in Scala in particular) which rely heavily on implicit context objects are more difficult to understand. For me, when trying to get my head around an unfamiliar codebase, explicit is better than implicit unless it introduces so much verbiage that the intent is hidden.
- mjburgess 4y ago
  I read this as a means of making the implictness of OO, explicit. Ie., it is syntax for specifying what `this` is Inheritance, fluid changing + properties, etc. are all implicit in exactly the same way. OO programmers have just got used to them

derriz 4y ago

Yes, you can achieve also reduce local readability by passing objects containing buckets of state around. But such classes always smell to me - particularly if component instances have other aliases. But I try to avoid it by designing distinct and hopefully coherent service or context classes. And this Kotlin feature effectively requires you structure your context/service/etc. classes in this way - the point is to allow multiple implicit contexts. When you say 'action-at-a-distance' - I would argue that the "distance" is not on the same scale. One crosses statements invisibly while your example, in all languages I've used, would still constitute a single statement. But fundamentally, this is an argument about style as it's not a pure binary distinction, so I don't think there's a definitive right or wrong here. Subjectively - in my experience, codebases (remembering one in Scala in particular) which rely heavily on implicit context objects are more difficult to understand. For me, when trying to get my head around an unfamiliar codebase, explicit is better than implicit unless it introduces so much verbiage that the intent is hidden.

mjburgess 4y ago
I read this as a means of making the implictness of OO, explicit. Ie., it is syntax for specifying what `this` is Inheritance, fluid changing + properties, etc. are all implicit in exactly the same way. OO programmers have just got used to them