HTTP/1.1 -1 Read error in cache disk data: SuccessContent-Type: text/tab-separated-values; charset="utf-8" Last-Modified: Sat, 22 Jan 2022 02:34:00 GMT Content-length: 1311 Connection: Close Proxy-Connection: Close X-Cache: HIT from web1.osuosl.org Server: ProxyTrack 0.5 (HTTrack 3.49.2) id summary reporter owner description type status priority milestone component version severity resolution keywords cc lang patch platform 903 [RFC] Deprecate Keys at all. bacek "Hello. (Background: I've spent few months trying to make Keys and Iterators more sane) There is excerpt from IRC log: {{{ chromatic: I've got excellent (fsvo) idea. Deprecate Keys at all. What would replace them? Create NamespaceKey which will be used for Namespaces. Navigating over ""ordinary"" aggregates will be ""manual"" The idea has merit. indeed. No one uses $P0[foo;bar;baz] It's almost impossible to implement and used correctly. And behaviour is very dependant on HLL It's not easy to manage in IMCC either. e.g. autovivify vs throwing exception. So, NamespaceKey will has-a RSA Simple, clean, comprehensible. Remove a lot of code in Hash and Array to support Keys. Simplify IMCC and future of PIRC (which doesn't support complex keys) It's worth considering. }}} Actually NamespaceKey can be is-a RSA. Then creating it in pir will be something like {{{ $P0 = split ';', 'foo;bar;baz' $P1 = new [NamespaceKey] $P1 = $P0 }}} -- Bacek" RFC new normal 2.6 core trunk medium Ct61-j559tSRR-dJfxUuQJCuvQltP1F5v8