I would be for: 

- deprecate #categories 
- add #protocols but not answering a string. Answer the protocol objects.

after all, the whole purpose of this is to reify the protocol concept. 

and of course, Nicolas is right… protocols *should not* answer allProtocol… or 
any other virtual protocol. I agree that answering in #categories is an error 
too… if we are going to change it, let’s not carry the original mistake. 

Esteban


On 28 May 2014, at 18:16, Nicolas Cellier <[email protected]> 
wrote:

> 
> 
> 
> 2014-05-28 22:49 GMT+02:00 stepharo <[email protected]>:
> 
> On 26/5/14 23:07, GOUBIER Thierry wrote:
> In my own code, I allways use ClassOrganization>>#realCategories to avoid 
> getting the --all-- category. I consider the --all-- category to be a GUI 
> artifact, not a class organization concept.
> 
> I'd prefer a #protocols (without the --all-- category, of course :)) so ok 
> for deprecating #categories.
> 
> +1 :)
> 
> Thierry
> ________________________________________
> De : Pharo-dev [[email protected]] de la part de Esteban 
> Lorenzano [[email protected]]
> Envoyé : lundi 26 mai 2014 21:20
> À : Pharo Development List
> Objet : [Pharo-dev] is ClassOrganization>>#categories right?
> 
> Hi,
> 
> I wonder is current implementation of that method is good: right now, it 
> answers all categories, including virtual ones (—all—).
> A lot of things are made in that assumption, but I wonder if is not better to 
> answer just real categories and to create a new method called #allCategories 
> to answer the reals and the virtuals.
> 
> Also, I wonder if wouldn’t be better to just deprecate #categories and use 
> the correct abstraction: #protocols.
> 
> any opinions?
> 
> Esteban
> 
> 
> 
> 
> 
> -1
> The sole purpose of categories is to provide backward compatibility support, 
> or am I mistaken?
> 
> If it's for backward compatibility, why the hell rename it?
> We have #categories -> #realCategories (to avoid bogus --all-- inclusion)  
> and now -> #protocols
> That's way too much erraticity.
> If the purpose is driving buts people caring of package management and cross 
> dialect compatibility, then +1, it's a successfull path ;)
> I know, I know, Pharo values clean API - protocols ;) - more than 
> compatibility, but cleaning a message dedicated to compatibility somehow 
> sounds too much.
> 
> If you opt for protocols, at least, please remove --all--

Reply via email to