You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once we can create new topics in the form of issues, refs #5, we want to reply to those issues by creating comments.
In this limited case, we can see comments and issues as forming a kind of meta-class called LETalk, with issues being a kind of container subclass of comments.
Realistically, comments can be attached to lots of classes we are simply not considering yet.
Therefore, we will have to make an architectural decision whether to have a set of keys the non-nil version of which tells what’s happening (as with UIViewController and friends) or to factor out the common “parent” object to which all comments can belong.
The text was updated successfully, but these errors were encountered:
…se case—attached to issues.
In the UI, issues and comments both contain some common conceptual sub-object called a talk, which has a body. (Seeing the problem as Composition versus Inheritance, Refs #31)
In the code, issues and comments are both kinds of talks, their common API unified behind the LETalk protocol.
In any case, the user may be replying to the top-level issue or one of its comments, but they both result in the same thing: a new comment being added to the issue.
Therefore, we have to disambiguate between whether the current talk is the issue, or the current talk is contained by the issue. For this we can introspect the actual class of the talk, and use the issue back pointer if necessary.
## Next steps
1. Create a comment and attach it to the issue.
2. Ensure this is done in a way that is compatible with the coming sync architecture.
3. Actually sync these changes.
Refs #30
## Experience
1. If you are looking at a talk that you have not changed, and you are in preview mode, the save button is a reply button.
2. Tapping the reply button creates a new comment and opens that comment in the editor.
3. Editing the comment works as expected, and is added to the conversation aka talk list.
## LEWorkViewController
* Finished the reply method, which now adds the new comment to the current issue or comment’s issue, refs #30
## GHIssue
* Add a comment adding method that conveniently adds the new comment to the issue.
* Add named constants for the comments key and property.
## GHComment
* Add a comment factory similar to that employed by GHIssue
* The difference being there is only one new comment.
* This will let us explore how to deal with unsynced comments and issues, refs #31
Once we can create new topics in the form of issues, refs #5, we want to reply to those issues by creating comments.
In this limited case, we can see comments and issues as forming a kind of meta-class called LETalk, with issues being a kind of container subclass of comments.
Realistically, comments can be attached to lots of classes we are simply not considering yet.
Therefore, we will have to make an architectural decision whether to have a set of keys the non-nil version of which tells what’s happening (as with UIViewController and friends) or to factor out the common “parent” object to which all comments can belong.
The text was updated successfully, but these errors were encountered: