@saberlong #29
@shellus #30

你说“定时”什么的，这不就得依赖系统时钟，增加额外的线程。当然实际项目完全可以这么干，有了“定时”，事情也就变得很简单了

而我其实是希望用纯数据结构纯算法来完成这个事，给自己增加点挑战~~

@stardust21 #27 删除肯定是满了才进行删除的，遍历也不太行，极端情况存了 10 万个数据，准备删除，难道先遍历看看谁过期了在删除？好吧，那万一要是全都没过期，那就很尴尬白忙活，只能乖乖按照 LRU 删最后一个

@xiaoming1992 #24
@zifangsky #25

其实都可以，目前我用 LRU 实现出来了
https://gist.github.com/mkanako/e8a279aa2ffd946bf7b3fd9c26479ef7


然后发现 LRU 实现出来有点问题，我的要求之一是数据有个有效期，而 LRU 只会删除队列最后一个

这样存在一种情况，队列最后一个数据没过期，但是倒数第二个是过期了，LRU 把最后这个没过期的删掉了，但是实际上倒数第二个更加应该被删除才对

@kamal #19 这思路感觉有点行啊，这么搞，如果一个数据（没过期）频繁被读取就会一直保持在队列前面，需要删除的时候就不容易被删，那些没怎么被读取的就会随着队列调整落在队尾，随时准备被删除~~

@ipwx #14 行吧都说是 LRU，我研究学习下。。。

@chihiro2014 #9 O(1)前提是你得知道 key 啊，问题是删除的时候根本不知道 key 是什么，得遍历根据条件去找符合要求的 key 然后删除啊

@kamal #8 时间和读取次数本来就没啥冲突啊，你这意思是读取变成会更新时间？？

@rabbbit #6 map 我感觉不行，key 类型不是关键啊

@luckyrayyy #2
@DonaldY #3
过期这个都比较好处理
极端情况 10 万条，都没过期，现在要插入新的，怎么删，不得遍历

定时删除暂不考虑，这不还得额外弄个线程干这事，增加复杂度，你要是做 redis,memcache 这样的东西，定时就很合理很必要

@rabbbit #15 save 方法既不是，也不应该是 PropertyDescriptor 的成员，即便不覆盖扩展它也是非常不合理的做法吧

@oott123 #12 原来可以是这样啊，没试过，学习了

@optional #11 你这样确实也可以，不过应该是_target.save.apply(this,args)

@rabbbit #5 本来 save 就不是 PropertyDescriptor 里面的方法，强行给他加个定义，并且这样还覆盖掉原版 PropertyDescriptor，不行啊

@optional #4 https://es6.ruanyifeng.com/#docs/decorator

装饰器第一个参数是类的原型对象，上例是 Person.prototype，装饰器的本意是要“装饰”类的实例，但是这个时候实例还没生成，所以只能去装饰原型（这不同于类的装饰，那种情况时 target 参数指的是类本身）；第二个参数是所要装饰的属性名，第三个参数是该属性的描述对象。

实测结果确实如此_target 不是 this 而是类本身

@oott123 #3 `descriptor.value = function (this: YourTypeHere, ...args: never)`这么搞相当于改变原函数的参数列表，调用方法的时候还得额外传个 this 参数，不行

初学 TS 瞎试一番，(this as MyClass).save()，这样就解决了，不过看起来似乎不太优雅？

@zjsxwc #11 看了这个 replace 属性，可以在 AB 不知觉的情况下替换掉 C，替换为我自己实现的 packageC-polyfill，最终就是为了解决冲突，我自己得去维护这个 C,还是不太满意
不过在某些情况这个 replace 属性是有点用处，学习了

@zjsxwc #9 你忘了一点，我项目依赖 A,B 这两个第三方包，然后 A,B 又依赖了 C，这个 C 显然也是第三方的，这 3 个包我根本无法修改他们的依赖关系
除非像 1L 楼说的 fork 一份出来修改

@jfcherng #7 这是无奈之举，根本问题是 composer 居然无法解决这种依赖问题，有点惊讶