chat: improve namespacing of chat-* types #2814

liam-fitzgerald · 2020-04-28T02:02:56Z

Namespacing proposal:

Never prefix a type with the name of the app. e.g. always action never chat-hook-action
All files in /lib and /sur should have ^? on the main core. ^? makes the payload opaque, which means you can't pull in imports indirectly. (e.g. you can't import lib/chat-hook to get at action:sur:chat-hook-lib)
Each app should have precisely one /sur and one /lib file
App-associated files in /sur should be imported as

/-  hook=chat-hook :: inside the context of chat
/-  chat-hook  :: outside the context of chat

Associated files in /sur should be imported as

/+  hook-lib=chat-hook
/+  chat-hook-lib=chat-hook

JSON conversion functions should be under +dejs or +enjs inside the associated /lib file.
Imports with * should be avoided as much as is reasonably possible, especially in /app files.

Implements the above proposal for the chat-* apps.

If everyone's happy with this, I'd like to extends this style to the rest of the codebase

Improved the namespacing by dropping the app prefix on types, e.g. chat-hook-action -> action. Compensated for shadowing by importing the /sur files behind a face. End result is that a chat-hook-action becomes an action:hook. Splits chat-json into lib/chat-{hook,store,view}. Uses ^? on changes files in /lib and /sur to discourage deeply nested importing.

matildepark · 2020-04-28T02:07:53Z

(Informal GitHub etiquette: only tag reviewers if they're required; cc optional reviews. This isn't codified yet iirc, but it helps clarify when merging.)

tacryt-socryp

Righteous! These are good conventions and these changes have been well-executed.

tacryt-socryp · 2020-04-28T03:03:43Z

pkg/arvo/mar/chat/view-action.hoon

  ++  json
    |=  jon=^json
-    (json-to-view-action jon)
+    (action:dejs jon)


You can just put ++ json action:dejs

tacryt-socryp · 2020-04-28T03:04:24Z

pkg/arvo/mar/chat/hook-action.hoon

  ++  json
    |=  jon=^json
-    (json-to-hook-action jon)
+    (action:dejs jon)


can replace with ++ json action:dejs

tacryt-socryp · 2020-04-28T03:04:32Z

pkg/arvo/mar/chat/action.hoon

  ++  json
    |=  jon=^json
-    (json-to-action jon)
+    (action:dejs jon)


Fang-

One thing I neglected to mention in conversation, @liam-fitzgerald, is that maybe lib and sur files for the stores themselves shouldn't have the -store suffix. Idea here being that the things in them are data structures and associated helpers for the entire suite of apps, not just the store.
So you'd get, for example, envelope:chat and action:chat in /sur/chat.hoon.

Wondering what you think of this. It does rub up against "1 file per app" a little bit, in that the relation is less literal.

Left some more comments below, but changes look good otherwise! Happy to see this done. (:

pkg/arvo/app/chat-hook.hoon

Fang- · 2020-04-28T12:11:03Z

pkg/arvo/app/chat-store.hoon

 :: chat-store: data store that holds linear sequences of chat messages
 ::
-/+  *chat-json, *chat-eval, default-agent, verb, dbug
+/-  store=chat-store


We discussed importing "native" types (and maybe libs) with *, and thought we agreed on that? Having :store suffixes, inside of the store, feels a little bit silly to me. (Same goes for the other apps.)

I've been flipping back and forth on this. I like having :store suffixes because

using the autoname syntax doesn't shadow the type.

It preserves a semblance of referential transparency inside the chat context. It's not uncommon to have to make changes to both the -store and -hook and I think preserving the namebindings is useful to prevent unnecessary context switches

Types aren't really that hard up for space in most common syntactical situations, so identifier length is not really an issue here.

"Each file can get one sur * or one lib *, after that things get too confusing" seems like a reasonable compromise. Otoh -lib suffixes appearing anywhere are a sign that something has gone obviously wrong, and imo a fairly strong argument for a "stacking" model of "a library will frequently subsume the structure by the same name, pull in only one of them" - I don't believe e.g. inbox-to-configs:store would be overly unclear compared to inbox-to-configs:store-lib.

Having libs and matching surs under the same namespace sounds pretty nice, yeah. Lacking support for simultaneous /- name=thing and /+ name=thing, doesn't seem too unreasonable to just expose the types with the lib, under the assumption you're gonna need them anyway.

pkg/arvo/lib/chat-store.hoon

pkg/arvo/lib/chat-view.hoon

liam-fitzgerald · 2020-04-28T22:13:30Z

One thing I neglected to mention in conversation, @liam-fitzgerald, is that maybe lib and sur files for the stores themselves shouldn't have the -store suffix. Idea here being that the things in them are data structures and associated helpers for the entire suite of apps, not just the store.
So you'd get, for example, envelope:chat and action:chat in /sur/chat.hoon.

Wondering what you think of this. It does rub up against "1 file per app" a little bit, in that the relation is less literal.

I kinda dislike this, because it implies (at least to me) that action:chat and action:chat-hook are somehow dependent, or that action:chat-hook is a subtype of action:chat. This is true for the chat apps, but is not necessarily the case for all apps. Also wondering how this works in relation to an incomplete 'suite' of apps. e.g. permission-group-hook.

ohAitch · 2020-04-29T17:58:49Z

Personally I would push for the ^? being part of the ford /- * syntax, so you can still structure things as multiple cores but have to be explicit about things. It's not being able to get at things at all that's an issue, it's them being spilled into a uniform namespace: if you see action:chat-sur:chat-lib due to both being qualified imports, you can follow that something funky is going on.

ohAitch · 2020-04-29T18:12:36Z

pkg/arvo/mar/chat/hook-update.hoon

 ++  grab
  |%
-  ++  noun  chat-hook-update
+  ++  noun  update


Something I don't love here is these are in fact being sent over the wire as %chat-hook-update, which might warrant some verbosity in at least the marks and !<s for consistency. (Alternately the mark system should perhaps have some manner of namespacing… even like, %chat-hook--update would make intermittent usage of the bare name less awkward)

Fang- · 2020-04-29T23:22:46Z

pkg/arvo/lib/chat-view.hoon

+/-  *chat-view, *rw-security
+|%


Hmm, but with the ^? removed, this would still expose the *rw-security. Wondering if there's some middle ground here where we can selectively expose only the types (core) "native" to the lib...

could we just cons the sur import and the library core together? and then ^? the result

Oh yeah, that seems to work.

You're gonna have to =, chat-view instead of importing as *chat-view though, which is bad-style use of =,. I guess the ends justify the means here.

Fang-

Alright, this seems good! (:

Fang- · 2020-04-30T09:38:56Z

pkg/arvo/lib/chat-store.hoon

+        %text
+    (frond %text s+text.letter)


Suggested change

%text

(frond %text s+text.letter)

%text

(frond %text s+text.letter)

The backsteps on these are still a bit too aggressive.

tacryt-socryp · 2020-05-01T03:02:37Z

Liam the indenting you “fixed” is wrong... it was right before

liam-fitzgerald · 2020-05-04T23:49:33Z

Pls approve @loganallenc @Fang-

tacryt-socryp · 2020-05-04T23:50:09Z

Morge

matildepark · 2020-05-05T00:47:03Z

You have a merge conflict here @liam-fitzgerald

tacryt-socryp · 2020-05-06T23:04:14Z

pkg/arvo/lib/chat-store.hoon

+  ++  letter
+    |=  =^letter
+    ^-  json
+    =,  enjs:format


unnecessary

What do you mean?

oh right the tiscom

tacryt-socryp · 2020-05-06T23:04:27Z

pkg/arvo/lib/chat-store.hoon

+  ++  config
+    |=  =^config
+    ^-  json
+    =,  enjs:format


unnecessary

matildepark · 2020-05-11T18:40:07Z

This has a merge conflict again.

When should this even be merged? And what target? It seems like these can go out whenever; they're more for developer benefit than user fixing.

Fang- · 2020-05-11T18:43:57Z

When should this even be merged? And what target?

afaic this can be merged when conflict is resolved, onto a release/next-userspace or release/next-ota.

matildepark · 2020-05-19T20:28:26Z

ping @liam-fitzgerald Mind fixing the conflicts and targeting release/next-userspace for this and the other namespacing PRs?

liam-fitzgerald · 2020-05-19T23:54:34Z

Don’t merge yet I have to port the virtualisation changes

matildepark · 2020-05-19T23:56:08Z

RIP sorry

You can make another PR for release/next-userspace?

liam-fitzgerald requested review from Fang-, ixv, matildepark and tacryt-socryp April 28, 2020 02:02

matildepark removed request for ixv and matildepark April 28, 2020 02:07

tacryt-socryp approved these changes Apr 28, 2020

View reviewed changes

Fang- reviewed Apr 28, 2020

View reviewed changes

chat: address review comments

531efa8

ohAitch reviewed Apr 29, 2020

View reviewed changes

chat: expose types with libs

d7a5499

Fang- reviewed Apr 29, 2020

View reviewed changes

chat: use ^? on libs correctly

c62140e

Fang- approved these changes Apr 30, 2020

View reviewed changes

chat: fix indenting

1faf359

liam-fitzgerald force-pushed the lf/chat-type-namespacing branch from 1ec3caa to 1faf359 Compare May 1, 2020 04:12

tacryt-socryp reviewed May 6, 2020

View reviewed changes

pkg/arvo/lib/chat-store.hoon Outdated

++ config

|= =^config

^- json

=, enjs:format

Copy link

Contributor

tacryt-socryp May 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unnecessary

liam-fitzgerald added 2 commits May 7, 2020 10:39

Merge branch 'master' into lf/chat-type-namespacing

cf8e8f8

chat-store: remove redundant tiscom

d7d07b0

liam-fitzgerald mentioned this pull request May 8, 2020

links: namespace types #2882

Merged

liam-fitzgerald changed the base branch from master to release/next-userspace May 19, 2020 23:16

Merge branch 'master' into lf/chat-type-namespacing

98e65bb

matildepark merged commit 91cf06b into release/next-userspace May 19, 2020

matildepark deleted the lf/chat-type-namespacing branch May 19, 2020 23:54

ixv mentioned this pull request May 24, 2020

fix minor issues ryjm/srrs#3

Merged

Uh oh!

chat: improve namespacing of chat-* types #2814

chat: improve namespacing of chat-* types #2814

Uh oh!

Conversation

liam-fitzgerald commented Apr 28, 2020

Uh oh!

matildepark commented Apr 28, 2020

Uh oh!

tacryt-socryp left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Fang- left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

liam-fitzgerald commented Apr 28, 2020

Uh oh!

ohAitch commented Apr 29, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

liam-fitzgerald Apr 29, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Fang- left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tacryt-socryp commented May 1, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

liam-fitzgerald commented May 4, 2020

Uh oh!

tacryt-socryp commented May 4, 2020

Uh oh!

matildepark commented May 5, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

matildepark commented May 11, 2020

Uh oh!

Fang- commented May 11, 2020

Uh oh!

matildepark commented May 19, 2020

Uh oh!

liam-fitzgerald commented May 19, 2020

Uh oh!

matildepark commented May 19, 2020

Uh oh!

Reviewers

liam-fitzgerald Apr 29, 2020 •

edited

Loading

tacryt-socryp commented May 1, 2020 •

edited

Loading