RFC: Proposed renaming scheme

[rlrh]

Proposed renaming scheme

Since we are going to start morphing the AddressBook soon, we should settle on a renaming scheme so work can be split up more easily.
In our discussions, we used Link to replace Person, however I think a better name is needed to avoid confusion.
Therefore, I'm proposing the following scheme, which tries to use similar terms as the Atom feed specification, and also tries to avoid naming conflicts with any of the libraries we are going to use.
Do give feedback or suggest how we can make this scheme better!

Updates

25/2: move siteName into Link, change feedLink type to Set<Link>
24/2: change Entries to EntryBook

Model

Old	New
(interface) ReadOnlyAddressBook	(interface) ReadOnlyEntryBook
AddressBook	EntryBook
VersionedAddressBook	VersionedEntryBook
UniquePersonList	UniqueEntryList
Person	Entry (currently “Link” as discussed)

Storage

Old	New
(interface) AddressBookStorage	(interface) EntryBookStorage
JsonAdaptedPerson	JsonAdaptedEntry
JsonAddressBookStorage	JsonEntryBookStorage
JsonSerializableAddressBook	JsonSerializableEntryBook

UI

Old	New
PersonCard	EntryCard
PersonListPanel	EntryListPanel

Entry class (replaces Person class)

Identity fields	Data fields (all optional)
link : Link - require non-null - isSame check only on this field	title : Title - from Crux, usually headline of news article or HTML <title> tag content - or user-overridden
	tags : Set - carried over
	(future) comment: Comment - user comments on the entry, e.g. why user saved the link
	(future) feedLinks: Set - added by Feeds component - used to filter entries by feeds
	(future) estimatedReadingTimeMinutes: Integer - estimated reading time from Crux
	(future) description: String - from Crux - used if available, otherwise summary is generated
	(future) heroImageLink : String - from Crux - url of hero image to be displayed in EntryCard

[thomastanck]

How about AddressBook -> EntryCollection? Entries sounds more like what you would call a variable of type Entry[].

[rlrh]

How about AddressBook -> EntryCollection? Entries sounds more like what you would call a variable of type Entry[].

I agree Entries is not ideal. However, using the word "collection" might confuse it with Java collections too...

[epicfailname]

feedLink should be a Set? Since a single link might have been present in multiple feeds

[epicfailname]

Should siteName be a property of Link instead?

[thomastanck]

feedLink should be a Set? Since a single link might have been present in multiple feeds

+1

Should siteName be a property of Link instead?

I think after the meeting it was decided that links refer to the actual URL while what we were calling link before is just Entry.

I don't think there's a strong need to make Link its own class, but if it was its own class, then we can probably move siteName into the Link class.

[rlrh]

Should siteName be a property of Link instead?

Makes sense. Eventually the UI EntryCard will display either the actual link or the site name is available. If siteName is a property of Link, then there should be a method like String getFriendlyRepresentation() in future that returns the extracted site name is available or the domain part of the URL without www and http

[rlrh]

feedLink should be a Set? Since a single link might have been present in multiple feeds

Oh yeah, didn't think of that, will update accordingly

[rlrh]

Should we store the date an entry is added or is it unnecessary?

[thomastanck]

Yeah, I think this is a good idea.

…

On 25 Feb 2019, at 17:57, Rayner Lim ***@***.***> wrote: Should we store the date an entry is added or is it unnecessary? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

[thomastanck]

Moving this to v1.3 as this is low priority.

Bulk of the renames are complete. The remaining renames are to be done progressively as we touch the code.