I do not think, design-wise, this is a good idea. In addition to what Tim said, extensions would become needlessly complex if we started accounting for every possible MediaWiki feature that's added in a given release. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com
On Thu, Oct 11, 2012 at 8:33 PM, Tim Starling <tstarl...@wikimedia.org>wrote: > On 12/10/12 04:03, Victor Vasiliev wrote: > > I think instead of using individual constant, we should finally > > introduce a Capabilities class. > > > > It should have a single static method, has(), which indicates whether > > a certain capability is registered within the system. At the > > beginning, capabilities will be listed as static members of that > > class, but we may do something more clever at the future. > > > > I would also suggest that we introduce a policy of adding a capability > > for any new hook we add. Or we could parse docs/hooks.txt in order to > > avoid duplication (probably moving it somewhere). > > > > Finally, backporting that interface into previous versions of > > MediaWiki might be a good idea. > > Then you would have to load a capability map with potentially hundreds > of entries at registration time, despite the fact that on most > requests, most of the hooks will never be called. It seems inefficient > to me. At least with the current system, the number of support > constants is small (4-5). > > -- Tim Starling > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
