On 14 March 2013 11:25, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Igor,
Please, let's keep the discussion at the level of arguments.
sorry.. we had conversations about that multiple times with Stef and Marcus. And it was sounded like we came to some consensus. But your statements actually an invitation to restart from where we come from..
The original reasons for developing RPackage were: - to offer a first class package object in the image and to remove the category-string-based-solution, and - to get rid of Monticello-magic-mapping, and potentially offer the option of adding tags as an orthogonal mechanism.
At this moment, we have RPackage mapped one-to-one to categories, but the core implementation still relies on categories. So, at the very least, we should find a way to remove categories and directly rely on RPackage.
yes. I was not part of development of RPackage.. and i still don't understand why it is so hard to make it map 1:1 to MC package instead of 1:1 to category. Category is nothing.. it is thin air.. it is the arbitrary name chosen by developer which he can change at any moment. It does not influencing anything at all (except from sorting the lists in browser).. A very simple rule: when you defining new class or recategorizing it, it will be added to package which name matching the category name (or first parts of it).. Does that sounds like technically impossible to implement? newclassCategory := 'Foo-Bugz' packageToAddTo := packages detect:[:ea | newclassCategory beginsWith: ea name ] ? I simply cannot find a good justification, why instead of doing small change in single place, we want to force numerous people do a lot of changes over whole world of packages. It doesn't sounds like a smart move. Especially if there would be clear benefit.. But there's not. At least i don't see one.
The Monticello mapping is there only for historical reasons. To eliminate it we need a strategy. For this, I see two options: - either we go with simply removing categories altogether and just relying on RPackages with 1-to-1 mappings to Monticello packages, - we introduce another mechanism (such as tags) that allows us to map categories on this.
yes this was added.. so we need last bit - make tags play role of categories. and make MC directly interact with RPackage for loading/snapshotting stuff. but since we cannot make everything at once, i hope gradually we will come there.
Perhaps there are other options, too.
Btw, I thought that in Pharo, backward compatibility is secondary to sound engineering :).
From machine's perspective , a package is just a collection of objects. Machine don't needs any naming there in order to make it run. Names are meaningful only to humans. So, categories/tags is extra metainformation which should be kept by package to make sure humans can understand it. Because if going to extreme, if you strip all names away, then you turning a package into unsorted set of objects, without any means to distinguish one from another by developers..
Does that sounds like 'sound engineering'? :)
Cheers, Doru
-- Best regards, Igor Stasenko.