FIG Cache Poll (Responses)
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
View only
 
 
ABCDEFGHIJKLMNOPQRSTU
1
TimestampYour nameWhich model (as described above) should FIG pursue?Are you a voting member of FIG?What project do you represent?What is your main reason for favoring that model?
2
6/17/2013 17:32:53Larry GarfieldStrong ItemYesDrupalAn interface standard needs to be extensible. It needs to be flexible. It needs to be more than just agreeing on method names. It should build a foundation. The weak model is not a foundation. It is just agreeing on method names. The Strong model has a clear path to extensibility (either by FIG or implementers), allows for far more experimentation by implementations (lazy loading, for instance), and allows CacheItem to be more than a glorified struct for which there is only one worthwhile implementation.

The weak model is backward-looking. The strong model is forward-looking. We should be forward looking.
3
6/17/2013 17:46:41Jeremy LindblomStrong ItemNoAWS SDK for PHPFuture extensibility.
4
6/17/2013 21:10:41Josh Hall-BachnerStrong ItemNostash-bundleStrong model is much more expandable and flexible.
5
6/17/2013 21:21:25Beau SimensenStrong ItemNoI prefer the simplicity and elegance of the strong item model. The separation of concerns are handled well. Actions that impact the cache system as a whole (clearing, getting an item) are the responsibility of the pool and the actions specific to an item (setting its value, ttl, etc) are the responsibility of the item itself.
6
6/18/2013 2:22:44William DurandStrong ItemYesPropel*A cache item has an identity and should behave as a domain's entity, so the strong item makes more sense than the weak one.
7
6/18/2013 2:37:09Matthieu NapoliWeak ItemNoSimilar to other caching libraries I've seen. More natural, more simple.
8
6/18/2013 2:57:34Jordi BoggianoStrong ItemYesComposerSeems like the better approach, even though less in use, but it's not dramatically different or more complex to use so I don't buy that "less in use" is a bad thing here.
9
6/18/2013 4:14:31.Strong ItemNo
10
6/18/2013 7:44:08Doru MoisaStrong ItemNoThere are cases when the $item is passed around, for ex. as a parameter to a method call. In this case, it is trivial to manipulate the $item, as it also has the knowledge to persist itself.
11
6/18/2013 10:09:35Chuck BurgessStrong ItemNophpDocumentor
12
6/18/2013 15:34:49Donald GilbertStrong ItemYesJoomlaI like that the item is responsible for it's own data.

However, I am not in favor of the item being responsible for saving itself. I would prefer an approach like this.

$item = $pool->getItem($key);
if ($item->isValid()) {
$data = $item->value();
}
else {
$data = something_expensive();
$item->setValue($data)->setTtl($ttl);
$pool->store($item);
}
return $data;

This keeps the Item from even being aware of it's storage mechanism, and it keeps the pool from inappropriate interaction with the Item. The pool is simply an item repository that stores and retrieves items. The item is responsible for interaction with its data.

This also allows for more complex storage mechanisms that can handle namespacing and other possible extensions through it's interaction with the item.

So maybe I favor an "Opinionated Item" instead of a strong or weak one?
13
6/18/2013 17:53:22Michael CullumStrong ItemNophpBBExtensibility
14
6/19/2013 2:56:05Marco PivettaWeak ItemNodoctrineMost of the PHP community doesn't really need advanced cache features: those can be setup for the cache pool itself internally.

In the case where more complex caches are needed, I see no problem in using specialized interfaces and NOT using a PSR cache.
15
6/20/2013 14:49:46beberleiWeak ItemNoDoctrinecache as a domain model seems a bit extreme for my taste.

additionally a standard is there to find the lowest common denominator, not to add ALL the features that no cache library even has at the moment. -1 on the strong item.
16
6/20/2013 16:06:05Martin ŠrankStrong ItemNoIt allows more extensibility in the future and makes more sense too (CacheItem is essentially a kind of Entity and Pool is a Repository).
17
6/20/2013 21:57:58Jeremy MikolaStrong ItemNoThe set() API itself is very limiting, so allowing the ability to add extra methods to an item depending on the implementation (I assume a few things will be common to the PSR, like TTL and value) seems preferable.

Based on PHP's internals, I don't see a big issue with having this item wrapper object, since copying data w/o modifying it is essentially free.

I do think a save() method is quite a departure from the persistence model of ORM/ODM, where we save objects via some other service and the model is a POPO, but I suppose there's no need for such overhead here?
18
6/22/2013 5:40:31Phil SturgeonStrong ItemYesPyroCMSBeing able to do more than basic K/V sounds great.
19
6/23/2013 19:41:33Guilherme BlancoStrong ItemYesDoctrineAllow more granular control over items and expansions for driver specific without breaking common API.
20
6/24/2013 13:58:00Can GelisStrong ItemNoWhy I use OOP is I love extending something and adding my own behaviors to the classes. For the Weak one, What if I want to use "ttl" for just miliseconds or seconds or hours etc. If the default "setTtl" is in miliseconds and I want to use it with seconds I can simply override the "setTtl" method.
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...
 
 
 
Form Responses