Skip to content
This repository has been archived by the owner on Feb 26, 2024. It is now read-only.

Revisit Linked List (Possible Unnecessary Duplication) #28

Closed
EisenbergEffect opened this issue Apr 23, 2014 · 5 comments
Closed

Revisit Linked List (Possible Unnecessary Duplication) #28

EisenbergEffect opened this issue Apr 23, 2014 · 5 comments

Comments

@EisenbergEffect
Copy link
Contributor

There are two implementations of linked list, one is in templating and the other is in watchtower. We should probably have a look at these and see if we can have a single implementation used in both places, then move this out to its own library.

See the related issue in templating: angular/templating#29

@caitp
Copy link
Contributor

caitp commented Apr 23, 2014

My feeling is that the linked list implementations actually don't share as much code as it looks like, because they use different property names. Even though the algorithm is pretty much identical, it's sort of awkward to share code.

It might be worth writing some shared helpers for asserting that there are no circular lists or anything, and make the property names configurable or something. I could see that helping with debugging.

@EisenbergEffect
Copy link
Contributor Author

I noticed the name differences and wandered if there was a good justification for that or if we might be able to get away with picking one set of names and then fixing up the dependencies in the other case. You know a lot better than I do. I'm just getting started looking into watchtower...and it will probably take me a bit of time to really grasp how it's working. I just wanted to make a quick note of this because it jumped out at me.

@caitp
Copy link
Contributor

caitp commented Apr 23, 2014

The justification is that certain types belong to multiple linked lists, so they need different names. It's a bit awkward.

@EisenbergEffect
Copy link
Contributor Author

Ah. I see that now. Interesting. Ok, well this is obviously pretty low priority. Maybe we can come up with some improvements later on. Maybe not.

@EisenbergEffect
Copy link
Contributor Author

I'm going to close. I'm not sure we can really make too many improvements hear yet. It really is a case of the same item participating in multiple lists so we need different vars to track things, etc.

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

No branches or pull requests

2 participants