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

KT-58965 (Consider moving content of subsection 4.1.1.1 to chapter 5): Possible resolution #132

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

MarkTheHopeful
Copy link

The reasons for and against are described in the corresponding issue on YouTrack.

Copy link
Contributor

@ice-phoenix ice-phoenix left a comment

Choose a reason for hiding this comment

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

To reiterate, the main question here is: where we should have the section and where we should have a reference to the section. Feel free to read the sections a bit more to get some more context and come up with an answer.

docs/src/md/kotlin.core/inheritance.md Outdated Show resolved Hide resolved
@@ -80,6 +80,85 @@ As Kotlin is a language with single inheritance (only one supertype can be a cla

TODO(Examples)

### Inheritance delegation
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you think the path Inheritance > Inheriting > Inheritance delegation is the best to place the section about inheritance delegation within the Inheritance section?

I have a feeling Inheriting talks about smth else, and there is another better-suited section in Inheritance to talk about inheritance delegation.

Copy link
Author

Choose a reason for hiding this comment

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

Remark: here the "Inheritance delegation" section is not located in the "Inheriting" section, but rather as an independent section directly inside the "Inheritance" chapter.

Apparently, if we are still considering places within the "Inheritance" chapter, it may seem meaningful to move the section to the "Classifier type inheritance", as, well, it does speak about the classifiers, but as I see it, "Classifier type inheritance" is more general, talking about what can actually be affected by inheritance, rather than about specifics of how.
The next section, "Matching and subsumption of declaration" describes which declarations can be considered as "matching", and thus a section about one specific case of inheritance ("Inheritance delegation") cannot be placed here or before it.
Next comes the "Inheriting" section, which, to be honest, just expands on the previous section, again, talking about general rules for inheritance.
The only section left is "Overriding", which is the only section finally introducing overriding and showing concrete examples.

Perhaps it may be meaningful to put it after the "Overriding" section, especially since "Inheritance delegation" references it, and, as it seems, is even more specific.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think I would prefer to place it right after the "Classifier type inheritance", tbh.

@@ -306,86 +306,6 @@ Inner classes cannot be declared in [object declarations][Object declaration], a
> }
> ```

##### Inheritance delegation
Copy link
Contributor

Choose a reason for hiding this comment

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

You made a great point in the issue, that this section is somewhere in between Inheritance and Declarations. One of the ways we use in the specification to reconcile such cases is to keep a forwards or backwards reference, saying "Well, actually we also have inheritance delegation, it is described in more detail [here][there]". So that the reader who comes to Declarations looking for inheritance delegation still can find the full description.

Copy link
Contributor

Choose a reason for hiding this comment

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

The main question to answer here is then: where should we have the actual section and where should we have the reference? In Declarations or in Inheritance? I would like you to think a bit more, make a decision and explain your reasoning.

Copy link
Author

Choose a reason for hiding this comment

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

On the one hand, it seems that the chapter Inheritance talks mainly about inheritance and redefinition rules, rather than specific cases, while Inheritance Delegation is a specific thing and syntax related to classifier declaration.
However, on the other hand, the previous location of Inheritance Delegation is hidden deep inside the class declaration and includes both the syntax for it (which is suitable for this chapter) and the inheritance logic with rules (which is more suitable for the chapter Inheritance). In addition, it uses some of the concepts presented later in the chapter Inheritance.

One simple solution in this case would be to somehow split the entire Inheritance Delegation section into two parts-one with syntax, an example (perhaps some technical details) in the Declarations chapter, where it is present right now, and another referring to the exact chapters and concepts from the section Inheritance could go to the Inheritance section itself. These two "parts" could be further connected to each other.

However, the most significant problem with this approach is that the section itself is quite small, and splitting it will result in two even smaller sections with incomplete information, and in order to understand one of them, the reader will need to read the other anyway.

If the "Split" approach is acceptable in this situation, then I would prefer it (even though how to do the splitting is a good question), as the section does not fully belong to either of the chapters.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks! I also agree that the split would be quite difficult. I think that we should keep the body of the section in "Declarations" and simply create the same-named section with reference to it in "Inheritance". WDYT?

Copy link
Author

Choose a reason for hiding this comment

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

Sounds good to me, will do so.
How much should be put to the section in inheritance? Just a reference will be too little for a section, and, I think, even for a subsection. If duplicating information is fine, then I guess I can put two first paragraphs of the original subsection into the new one, with third being somewhere around "Technical details and examples can be found in ". Or even put only the first one along with a small syntax example and just a few sentences from the second one, along with the reference...

Copy link
Contributor

Choose a reason for hiding this comment

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

It can be very minimal, for example, we have this very short section: https://kotlinlang.org/spec/built-in-types-and-their-semantics.html#built-in-annotation-types =)

But feel free to propose a more suitable split or reference.

@ice-phoenix
Copy link
Contributor

@MarkTheHopeful Could I ask you to proceed with the discussed changes, squash the fixups and force-push to your branch? Thanks!

@MarkTheHopeful
Copy link
Author

@ice-phoenix Done, decided to go with a small one-sentence-subsection with a reference. Fixups squashed and force-pushed.

Is the wording I used fine? I think trying to add anything else will result in duplication of already existing information from the corresponding subsection in the Declarations chapter.

Copy link
Contributor

@ice-phoenix ice-phoenix left a comment

Choose a reason for hiding this comment

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

👍

@ice-phoenix
Copy link
Contributor

Could you please rebase onto the updated develop once again?

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

Successfully merging this pull request may close these issues.

2 participants