Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback about A/HC/LC Pattern #35

Open
darcyparker opened this issue Jan 22, 2021 · 0 comments
Open

Feedback about A/HC/LC Pattern #35

darcyparker opened this issue Jan 22, 2021 · 0 comments

Comments

@darcyparker
Copy link

Can you add some additional references/sources for the A/HC/LC pattern you document?

I am familiar with similar standards from BPM (Business Process Management) world where steps are written verb-noun format.
The noun is the input to the step, and the output is noun-verbed. (The BPM book Workflow Modeling is one reference for this verb-noun format) This A/HC/LC pattern has many similarities to naming conventions in the BPM domain. (A good thing for learning/adopting one if you are familiar with the other.)

I read and understood most of the A/HC/LC pattern, but I have some doubts and wondered if its just something that could be explained better. I did not find anything with google when I searched... It feels like there is something good here, so I read it a few times and there are some areas that I am not getting 100% or that I find confusing.

  • I understand the differences with shouldUpdateComponent and shouldComponentUpdate example when I reflect on their meaning without looking at the grammar you defined.
    • But if I look at the grammar, the 2nd case is not mentioned. I think you should consider explicitly defining the prefix? + high context (HC) + action (A) + low context? (LC) case too.
    • In your example there are 2 resources: component and an unknown subject. By a convention/assumption, this unknown subject is to be understood as you. I can accept there is some convention for how to interpret dropped information... But I'd like more explanation about this convention so that I understand how to use the convention safely and have confidence downstream readers will correctly decode there is a 2nd resource and infer who the unknown resource is.
  • Is it true that the "context" (HC or LC) is a noun? If so, I think it would be helpful to say so. This will help people who are familiar with verb-noun and noun-verbed naming conventions. As I read about HC/LC, I want it to be true that they are nouns, but 'click' and 'post' examples in the table are usually verbs... an indicator I am interpreting this wrong... or there needs to be some improvement in explaining things. Perhaps there is an implicit transformation of these verbs into nouns for this context? And this transformation needs to be pointed out because the word can be a verb or noun. Or maybe this is another case of a noun (subject) being dropped like the shouldUpdateComponent being short for shouldYouUpdateComponent?
  • Maybe getPost is an idiom? I think you're talking about the HTTP verb POST. And when I look at it without thinking about this A/HC/LC pattern, I immediately interpret it as getting the posted data or getting the data to be posted. getPost seems to have dropped some detail because it doesn't map to a complete sentence. Hence my thinking that it is an idiom; idioms are learned and are confusing if they aren't explained. My issue with the getPost example is not that I don't understand this specific example's meaning, but that I can't relate it well to the A/HC/LC pattern's grammar. Something about the meaning has been truncated - and its expected I can figure out the meaning without it.
  • It is common to transform a verb into a noun... For example: 'walk dog' (verb noun) can be transformed into another action get dog walker where walk is transformed into walker. This second action is (verb noun noun). Here I think the tuple [noun noun] is an example of HC/LC that you are talking about? post data has the same verb-noun pattern... so using similar transformation I could define another action get data posted (which is like get dog walker). By the previous logic, if get post is an idiom for get data posted, then would get dog be an idiom for get dog walker? Perhaps... but like any idiom, its not going to be clear to some people.

I think there is some good guidance... but to me it feels like it is not quite complete (refined enough for my taste)... (or I am missing something). But its on its way to being complete.

It may be that I need to invest more time to fully understand it, or the writing needs to be refined... or a bit of both.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant