Hi, I am sorry to have wasted your time.
Cheers, Doru On Thu, Mar 14, 2013 at 1:06 PM, Marcus Denker <[email protected]>wrote: > 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. > > > > > -- www.tudorgirba.com "Every thing has its own flow"
