Can we please first release 2.0 before we waste all our energy in useless discussions?
On Mar 14, 2013, at 1:02 PM, Igor Stasenko <[email protected]> wrote: > On 14 March 2013 11:25, Tudor Girba <[email protected]> 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. >
