[Pharo-project] packages :)
Hi I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok. Now I would really like if - somebody could have a look at the code - develop a simple package browser showing class extensions (it would help me to define a good api to walk though a package). I started to use Momo and this is why I reimplemented the class but so far I get nearly the same interface and I think that I can do better. Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far - integration with MC - migrating from packageInfo - event notification are missing. Stef
Can you provide a Gofer expression to load it? Lukas On 16 March 2010 17:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok.
Now I would really like if     - somebody could have a look at the code     - develop a simple package browser showing class extensions (it would help me to define     a good api to walk though a package). I started to use Momo and this is why I reimplemented the class     but so far I get nearly the same interface and I think that I can do better.
Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far     - integration with MC     - migrating from packageInfo     - event notification     are missing.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Hi, To get it: Gofer new squeaksource: 'PharoTaskForces'; package: 'RPackageAll'; load. To get a super-simple browser that shows extensions in italics: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. To execute it on a super simple package structure: RMockFilledPackageOrganizer fillUp. (Smalltalk at: #GTCoder) openOn: RMockFilledPackageOrganizer default Cheers, Doru On 16 Mar 2010, at 17:23, Lukas Renggli wrote:
Can you provide a Gofer expression to load it?
Lukas
On 16 March 2010 17:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok.
Now I would really like if - somebody could have a look at the code - develop a simple package browser showing class extensions (it would help me to define a good api to walk though a package). I started to use Momo and this is why I reimplemented the class but so far I get nearly the same interface and I think that I can do better.
Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far - integration with MC - migrating from packageInfo - event notification are missing.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Reasonable is what we are accustomed with."
Thank you, I will give it a try (fed up writing). Lukas On 16 March 2010 18:00, Tudor Girba <tudor.girba@gmail.com> wrote:
Hi,
To get it: Gofer new     squeaksource: 'PharoTaskForces';     package: 'RPackageAll';     load.
To get a super-simple browser that shows extensions in italics:
Gofer new     squeaksource: 'glamoroust';     package: 'ConfigurationOfGlamoroust';     load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault.
To execute it on a super simple package structure: RMockFilledPackageOrganizer fillUp. (Smalltalk at: #GTCoder) openOn: RMockFilledPackageOrganizer default
Cheers, Doru
On 16 Mar 2010, at 17:23, Lukas Renggli wrote:
Can you provide a Gofer expression to load it?
Lukas
On 16 March 2010 17:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok.
Now I would really like if    - somebody could have a look at the code    - develop a simple package browser showing class extensions (it would help me to define    a good api to walk though a package). I started to use Momo and this is why I reimplemented the class    but so far I get nearly the same interface and I think that I can do better.
Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far    - integration with MC    - migrating from packageInfo    - event notification    are missing.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Reasonable is what we are accustomed with."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Thank you, I will give it a try (fed up writing).
this is a good sign :) Stef
Lukas
On 16 March 2010 18:00, Tudor Girba <tudor.girba@gmail.com> wrote:
Hi,
To get it: Gofer new squeaksource: 'PharoTaskForces'; package: 'RPackageAll'; load.
To get a super-simple browser that shows extensions in italics:
Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault.
To execute it on a super simple package structure: RMockFilledPackageOrganizer fillUp. (Smalltalk at: #GTCoder) openOn: RMockFilledPackageOrganizer default
Cheers, Doru
On 16 Mar 2010, at 17:23, Lukas Renggli wrote:
Can you provide a Gofer expression to load it?
Lukas
On 16 March 2010 17:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok.
Now I would really like if - somebody could have a look at the code - develop a simple package browser showing class extensions (it would help me to define a good api to walk though a package). I started to use Momo and this is why I reimplemented the class but so far I get nearly the same interface and I think that I can do better.
Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far - integration with MC - migrating from packageInfo - event notification are missing.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Reasonable is what we are accustomed with."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I have some comments, to both the package implementation and the Glamour browser. The other browser didn't work, I guess I miss some extra package. - I used the code below to import the existing packages into the new model. Maybe something like this should be included on the class side of RPackageOrganizer to have a realistic model? | package | PackageOrganizer default packages do: [ :info | package := RPackage2 named: info packageName. info classes do: [ :each | package addClassDefinition: each ]. info coreMethods do: [ :each | each isValid ifTrue: [ package addMethod: each compiledMethod isExtension: false ] ]. info extensionMethods do: [ :each | each isValid ifTrue: [ package addMethod: each compiledMethod isExtension: true ] ] ] displayingProgress: 'Importing' Then I opened the glamour browser using: GTCoder openOn: RPackageOrganizer default - I find it quite strange that I have to declare if a method is an extension or not. Isn't a that obvious when looking at the defined classes? Having two dictionaries for methods makes it extremely difficult to move stuff around because always 4 separate cases need to be handled. - The fact that compiled methods are stored in the model is very dangerous. You might hold onto compiled methods that have long been replaced with other ones. Just by playing a bit with the model I run into that situation (I don't know how). I think just keeping the selector internally would be much safer and solve all kinds of troubles (exactly like this is done for the classes). You'll have to check anyway if the method is still present when you iterate over the methods. A single use of #doSilently: (and there are lots of them in the image) can completely screw up the complete package model. - The browser displays nicely the extended classes, but for the methods I don't see the protocols and the complete set of selectors implemented. I think these things should be part of the browser, otherwise we don't see if the package model can answer these queries quick enough. - The browser displays extension methods on both instance and class-side. When browsing an extended class, the extensions are not displayed. That's it for the moment. I see a cool model emerging :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Hi Lukas, On 16 Mar 2010, at 21:50, Lukas Renggli wrote:
I have some comments, to both the package implementation and the Glamour browser. The other browser didn't work, I guess I miss some extra package.
- I used the code below to import the existing packages into the new model. Maybe something like this should be included on the class side of RPackageOrganizer to have a realistic model?
| package | PackageOrganizer default packages do: [ :info | package := RPackage2 named: info packageName. info classes do: [ :each | package addClassDefinition: each ]. info coreMethods do: [ :each | each isValid ifTrue: [ package addMethod: each compiledMethod isExtension: false ] ]. info extensionMethods do: [ :each | each isValid ifTrue: [ package addMethod: each compiledMethod isExtension: true ] ] ] displayingProgress: 'Importing'
Then I opened the glamour browser using:
GTCoder openOn: RPackageOrganizer default
- I find it quite strange that I have to declare if a method is an extension or not. Isn't a that obvious when looking at the defined classes?
Stef said that this was a reminiscent from before deciding he wants to declare the class explicitly, but we agreed that specifying the extension explicitly is not necessary.
Having two dictionaries for methods makes it extremely difficult to move stuff around because always 4 separate cases need to be handled.
I also do not like this part either.
- The fact that compiled methods are stored in the model is very dangerous. You might hold onto compiled methods that have long been replaced with other ones. Just by playing a bit with the model I run into that situation (I don't know how). I think just keeping the selector internally would be much safer and solve all kinds of troubles (exactly like this is done for the classes). You'll have to check anyway if the method is still present when you iterate over the methods. A single use of #doSilently: (and there are lots of them in the image) can completely screw up the complete package model.
The model does not store compiled methods, or classes. It only stores symbols.
- The browser displays nicely the extended classes, but for the methods I don't see the protocols and the complete set of selectors implemented. I think these things should be part of the browser, otherwise we don't see if the package model can answer these queries quick enough.
I agree, but this was just a quick thing to see what kind of navigation methods are needed to get the classes and methods. Categories are still to be added.
- The browser displays extension methods on both instance and class-side. When browsing an extended class, the extensions are not displayed.
Yes, these were bugs :). I tried to fix these, but I think I bumped into other problems, so I will stop for now. Cheers, Doru
That's it for the moment. I see a cool model emerging :-)
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Sometimes the best solution is not the best solution."
- The fact that compiled methods are stored in the model is very dangerous. You might hold onto compiled methods that have long been replaced with other ones. Just by playing a bit with the model I run into that situation (I don't know how). I think just keeping the selector internally would be much safer and solve all kinds of troubles (exactly like this is done for the classes). You'll have to check anyway if the method is still present when you iterate over the methods. A single use of #doSilently: (and there are lots of them in the image) can completely screw up the complete package model.
The model does not store compiled methods, or classes. It only stores symbols.
True, sorry about that. I did not open the inspector wide enough and I somehow made that conclusion from the public API :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Having two dictionaries for methods makes it extremely difficult to move stuff around because always 4 separate cases need to be handled.
I also do not like this part either.
Lukas this is exactly as in RBEnvironment as you suggested when you visited me. If you do not want to hold on class object but name as dictionary key you do not want to have a key that is 'Point class' because you end up been forced to do a lot of string matching shit. Now this is really simple and fast.
The model does not store compiled methods, or classes. It only stores symbols.
I prefer that ;)
- The browser displays nicely the extended classes, but for the methods I don't see the protocols and the complete set of selectors implemented. I think these things should be part of the browser, otherwise we don't see if the package model can answer these queries quick enough.
I agree, but this was just a quick thing to see what kind of navigation methods are needed to get the classes and methods. Categories are still to be added.
- The browser displays extension methods on both instance and class-side. When browsing an extended class, the extensions are not displayed.
Yes, these were bugs :). I tried to fix these, but I think I bumped into other problems, so I will stop for now.
Like what?
Cheers, Doru
That's it for the moment. I see a cool model emerging :-)
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 17 March 2010 09:39, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Having two dictionaries for methods makes it extremely difficult to move stuff around because always 4 separate cases need to be handled.
I also do not like this part either.
Lukas this is exactly as in RBEnvironment as you suggested when you visited me. If you do not want to hold on class object but name as dictionary key you do not want to have a key that is 'Point class' because you end up been forced to do a lot of string matching shit. Now this is really simple and fast.
The model does not store compiled methods, or classes. It only stores symbols.
I prefer that ;)
Sorry, I mis-inspected the object model. Forget all I said in that paragraph, it is invalid. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Mar 16, 2010, at 9:50 PM, Lukas Renggli wrote:
I have some comments, to both the package implementation and the Glamour browser. The other browser didn't work, I guess I miss some extra package.
- I used the code below to import the existing packages into the new model. Maybe something like this should be included on the class side of RPackageOrganizer to have a realistic model?
| package | PackageOrganizer default packages do: [ :info | package := RPackage2 named: info packageName. info classes do: [ :each | package addClassDefinition: each ]. info coreMethods do: [ :each | each isValid ifTrue: [ package addMethod: each compiledMethod isExtension: false ] ]. info extensionMethods do: [ :each | each isValid ifTrue: [ package addMethod: each compiledMethod isExtension: true ] ] ] displayingProgress: 'Importing'
Then I opened the glamour browser using:
GTCoder openOn: RPackageOrganizer default
- I find it quite strange that I have to declare if a method is an extension or not. Isn't a that obvious when looking at the defined classes?
Historically it was like you said in implementation 1 and 2, then I removed the defined classes (implementation 3), then I realized oops shit, we can have package with class but no methods (and in this case we should always when removing a method check if this is the last one and if there is none in the metaclass to trigger a classremoved event), so I reintroduced defined classes as a separate data (implementation 4 = now). Now I think that we should remove isExtension to go back to the first implementation. I guess that this is a todo
Having two dictionaries for methods makes it extremely difficult to move stuff around because always 4 separate cases need to be handled.
I discussed that point with doru when you went off your office.
- The fact that compiled methods are stored in the model is very dangerous.
There should not be or doru changes my code!!!
You might hold onto compiled methods that have long been replaced with other ones. Just by playing a bit with the model I run into that situation (I don't know how). I think just keeping the selector internally would be much safer and solve all kinds of troubles (exactly like this is done for the classes).
but this is like that. Doru?
You'll have to check anyway if the method is still present when you iterate over the methods. A single use of #doSilently: (and there are lots of them in the image) can completely screw up the complete package model.
- The browser displays nicely the extended classes, but for the methods I don't see the protocols and the complete set of selectors implemented. I think these things should be part of the browser, otherwise we don't see if the package model can answer these queries quick enough.
- The browser displays extension methods on both instance and class-side. When browsing an extended class, the extensions are not displayed.
That's it for the moment. I see a cool model emerging :-)
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 16 March 2010 19:00, Tudor Girba <tudor.girba@gmail.com> wrote:
Hi,
To get it: Gofer new     squeaksource: 'PharoTaskForces';     package: 'RPackageAll';     load.
I tried to do that in core image, and found that it having unresolved dependencies on: MorhTreeModel and MorphTreeNodeModel what package i need for them?
To get a super-simple browser that shows extensions in italics:
Gofer new     squeaksource: 'glamoroust';     package: 'ConfigurationOfGlamoroust';     load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault.
To execute it on a super simple package structure: RMockFilledPackageOrganizer fillUp. (Smalltalk at: #GTCoder) openOn: RMockFilledPackageOrganizer default
Cheers, Doru
On 16 Mar 2010, at 17:23, Lukas Renggli wrote:
Can you provide a Gofer expression to load it?
Lukas
On 16 March 2010 17:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok.
Now I would really like if    - somebody could have a look at the code    - develop a simple package browser showing class extensions (it would help me to define    a good api to walk though a package). I started to use Momo and this is why I reimplemented the class    but so far I get nearly the same interface and I think that I can do better.
Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far    - integration with MC    - migrating from packageInfo    - event notification    are missing.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Reasonable is what we are accustomed with."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On 17 March 2010 08:35, Igor Stasenko <siguctua@gmail.com> wrote:
On 16 March 2010 19:00, Tudor Girba <tudor.girba@gmail.com> wrote:
Hi,
To get it: Gofer new     squeaksource: 'PharoTaskForces';     package: 'RPackageAll';     load.
I tried to do that in core image, and found that it having unresolved dependencies on: MorhTreeModel and MorphTreeNodeModel
what package i need for them?
Oh, sorry, it was wrong image (1.0).
To get a super-simple browser that shows extensions in italics:
Gofer new     squeaksource: 'glamoroust';     package: 'ConfigurationOfGlamoroust';     load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault.
To execute it on a super simple package structure: RMockFilledPackageOrganizer fillUp. (Smalltalk at: #GTCoder) openOn: RMockFilledPackageOrganizer default
Cheers, Doru
On 16 Mar 2010, at 17:23, Lukas Renggli wrote:
Can you provide a Gofer expression to load it?
Lukas
On 16 March 2010 17:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok.
Now I would really like if    - somebody could have a look at the code    - develop a simple package browser showing class extensions (it would help me to define    a good api to walk though a package). I started to use Momo and this is why I reimplemented the class    but so far I get nearly the same interface and I think that I can do better.
Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far    - integration with MC    - migrating from packageInfo    - event notification    are missing.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Reasonable is what we are accustomed with."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
I forgot to mention You should load RPackage-All from PharoTaskForces Stef On Mar 16, 2010, at 5:21 PM, Stéphane Ducasse wrote:
Hi
I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok.
Now I would really like if - somebody could have a look at the code - develop a simple package browser showing class extensions (it would help me to define a good api to walk though a package). I started to use Momo and this is why I reimplemented the class but so far I get nearly the same interface and I think that I can do better.
Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far - integration with MC - migrating from packageInfo - event notification are missing.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Stef, i took a look on your implementation and i don't like it. :) It tries to work with methods and classes through symbolic names.. and you immediately end up with gemmorage of a need to keep separate 'core' and 'extension' , 'meta' and 'instance-side' methods in your model. By looking at: addSelector: aSelector ofClass: aClass "Add the method to the receiver. If the class is not locally defined in that package then the method is defined as a method extension: ie extending another package. The method is not added to the class." aClass isMeta ifTrue: [(metaclassSelectors at: aClass soleInstance name asSymbol ifAbsentPut: [Set new]) add: aSelector.] ifFalse: [(classSelectors at: aClass name asSymbol ifAbsentPut: [Set new]) add: aSelector.]. This approach, from very starting, unnecessary complexifies the model, and requires a lot of glue code. I don't know what is the purpose of making a package to be a dead piece of flesh, which reflects own organization by using symbols, instead of real objects? Who are you trying to deceive with that? If you remember, i put some thoughts about packages here before. And even implemented a prototype package model myself (did you looked at it?). My concepts is simple and object-oriented (instead of symbolic-names oriented ;) ) : If we take a most abstract and stripped down concept then, in order to define a package, we need just two things: - a set of objects , which belong to that package - and a namespace (name->object), where name is a symbol and object is one of the objects, which belong to package. note, that there is no any 'methods' or 'classes' . It is just objects and names. And then you can start adding flesh on that skeleton by implementing things , like covenient adding/defining/lookup classes, methods , etc etc. But if you don't that , you model will remain a piece of flesh, without skeleton - it can't move , it can only lie on the ground and rot :) I don't understand, why to not work with actual objects, instead of names? Please enlighten me, why you want to refer to objects indirectly and leaving to somethings else in the system to decide how these names turned into a real objects. What is the benefit of having such indirect model? In such form, a package becomes only a view of something which already exists in a system without it. It doesn't defining a domain space - just reflecting existing one (a years-old existing system organization (classes and methods)). And thus, you will have a hard times when you would want to migrate to a new system organization, because all levers of control lying elsewhere, instead in a package itself. On 16 March 2010 18:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok.
Now I would really like if     - somebody could have a look at the code     - develop a simple package browser showing class extensions (it would help me to define     a good api to walk though a package). I started to use Momo and this is why I reimplemented the class     but so far I get nearly the same interface and I think that I can do better.
Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far     - integration with MC     - migrating from packageInfo     - event notification     are missing.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
It tries to work with methods and classes through symbolic names.. and you immediately end up with gemmorage of a need to keep separate 'core' and 'extension' , 'meta' and 'instance-side' methods in your model.
Yes, that's what I suggested, merge the extension and core dictionaries.
I don't know what is the purpose of making a package to be a dead piece of flesh, which reflects own organization by using symbols, instead of real objects? Who are you trying to deceive with that?
Incremental development. Separation of concerns. If the package would contain the real classes and real methods one had to change (literally) thousands of places in the system.
If you remember, i put some thoughts about packages here before. And even implemented a prototype package model myself (did you looked at it?). My concepts is simple and object-oriented (instead of symbolic-names oriented ;) ) :
Where?
If we take a most abstract and stripped down concept then, in order to define a package, we need just two things: - a set of objects , which belong to that package - and a namespace (name->object), where name is a symbol and object is one of the objects, which belong to package.
RPackage is about a PackageInfo replacement, not about a namespace implementation. Arguably namespacing is something entirely different.
But if you don't that , you model will remain a piece of flesh, without skeleton - it can't move , it can only lie on the ground and rot :)
I suggested Stef to look at the environments in the refactoring engine. They are a proven implementation for more than 10 years, they work very efficiently with numerous GUIs (OB, VisualWorks, VisualAge), and have been applied in many different scenarios (introspection, reflection, refactorings, changes, lint, virtual code, ...).
I don't understand, why to not work with actual objects, instead of names? Please enlighten me, why you want to refer to objects indirectly and leaving to somethings else in the system to decide how these names turned into a real objects. What is the benefit of having such indirect model?
What would a method object refer to other than its class and its selector? Is the introduction of another layer of objects that duplicates Class, PseudoClass, MCClassDefinition, RBClass and CompiledMethod, MethodReference, MCMethodDefinition, RBMethod reasonable? Remember, this is just the internal implementation. I agree that to the outside a package should be represented using dedicated objects. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Mar 17, 2010, at 9:23 AM, Lukas Renggli wrote:
It tries to work with methods and classes through symbolic names.. and you immediately end up with gemmorage of a need to keep separate 'core' and 'extension' , 'meta' and 'instance-side' methods in your model.
Yes, that's what I suggested, merge the extension and core dictionaries.
I do not see how? without first class class and no string match: '* class' ? I'm curious
I don't know what is the purpose of making a package to be a dead piece of flesh, which reflects own organization by using symbols, instead of real objects? Who are you trying to deceive with that?
Incremental development. Separation of concerns.
If the package would contain the real classes and real methods one had to change (literally) thousands of places in the system.
Igor what happen when your class change shape. I do not know if it is becomed but if it is not we are in trouble.
RPackage is about a PackageInfo replacement, not about a namespace implementation. Arguably namespacing is something entirely different.
Yes
But if you don't that , you model will remain a piece of flesh, without skeleton - it can't move , it can only lie on the ground and rot :)
I suggested Stef to look at the environments in the refactoring engine. They are a proven implementation for more than 10 years, they work very efficiently with numerous GUIs (OB, VisualWorks, VisualAge), and have been applied in many different scenarios (introspection, reflection, refactorings, changes, lint, virtual code, ...).
This is what I did. Now in RB they do not deal with extensions.
I don't understand, why to not work with actual objects, instead of names? Please enlighten me, why you want to refer to objects indirectly and leaving to somethings else in the system to decide how these names turned into a real objects. What is the benefit of having such indirect model?
What would a method object refer to other than its class and its selector? Is the introduction of another layer of objects that duplicates Class, PseudoClass, MCClassDefinition, RBClass and CompiledMethod, MethodReference, MCMethodDefinition, RBMethod reasonable?
Remember, this is just the internal implementation. I agree that to the outside a package should be represented using dedicated objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Stef, On 17 Mar 2010, at 09:50, Stéphane Ducasse wrote:
On Mar 17, 2010, at 9:23 AM, Lukas Renggli wrote:
It tries to work with methods and classes through symbolic names.. and you immediately end up with gemmorage of a need to keep separate 'core' and 'extension' , 'meta' and 'instance-side' methods in your model.
Yes, that's what I suggested, merge the extension and core dictionaries.
I do not see how? without first class class and no string match: '* class' ? I'm curious
The issue is not between instance side and meta side. The issue is with having two dictionaries for each: one for extensions and one for definitions. If we have the information about which classes are defined in this package, we only need to store the methods for the class and we know which are extensions and which are not. Cheers, Doru -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."
On Mar 17, 2010, at 10:05 AM, Tudor Girba wrote:
Hi Stef,
On 17 Mar 2010, at 09:50, Stéphane Ducasse wrote:
On Mar 17, 2010, at 9:23 AM, Lukas Renggli wrote:
It tries to work with methods and classes through symbolic names.. and you immediately end up with gemmorage of a need to keep separate 'core' and 'extension' , 'meta' and 'instance-side' methods in your model.
Yes, that's what I suggested, merge the extension and core dictionaries.
I do not see how? without first class class and no string match: '* class' ? I'm curious
The issue is not between instance side and meta side. The issue is with having two dictionaries for each: one for extensions and one for definitions. If we have the information about which classes are defined in this package, we only need to store the methods for the class and we know which are extensions and which are not.
this is not that simple. For each class I have to know the methods (defined | extended) So I have to encode that information why because not all the methods of a defined class are defined in a package! The class point defined in package graphics can be extended by myPackage and these methods should not be part of the Graphics. So I always need three information Class * method * extended|defined
Cheers, Doru
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Stef, On 17 Mar 2010, at 11:09, Stéphane Ducasse wrote:
On Mar 17, 2010, at 10:05 AM, Tudor Girba wrote:
Hi Stef,
On 17 Mar 2010, at 09:50, Stéphane Ducasse wrote:
On Mar 17, 2010, at 9:23 AM, Lukas Renggli wrote:
It tries to work with methods and classes through symbolic names.. and you immediately end up with gemmorage of a need to keep separate 'core' and 'extension' , 'meta' and 'instance-side' methods in your model.
Yes, that's what I suggested, merge the extension and core dictionaries.
I do not see how? without first class class and no string match: '* class' ? I'm curious
The issue is not between instance side and meta side. The issue is with having two dictionaries for each: one for extensions and one for definitions. If we have the information about which classes are defined in this package, we only need to store the methods for the class and we know which are extensions and which are not.
this is not that simple. For each class I have to know the methods (defined | extended) So I have to encode that information why because not all the methods of a defined class are defined in a package!
The class point defined in package graphics can be extended by myPackage and these methods should not be part of the Graphics.
So I always need three information Class * method * extended|defined
Not quite. At this moment, for any given class in a package, you can either have entries in the defined or in the extension dictionaries, but not in both in the same time. So, this is an indication that you can simply merge the two dictionaries. As soon as you add a method to a package, you know exactly if that method is defined or not by knowing whether the class is defined in that package. Also, if you do have the methods in one dictionary, then you also won't have to care whether you moved the definition of a class between packages. Right now, if you move the definition of a class without touching the methods, you will have to ensure in the two packages that the methods that were defined are not extensions and the other way around. If you interpret the extension by looking at where the class is defined, then you do not lose anything. Yet another point is that I typically first want to know the methods of a class from a package. I do not want to know which is extended or which is not. So, I currently have to look it up in two dictionaries which is not necessarily optimal. Or am I missing something? Cheers, Doru -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."
So I always need three information Class * method * extended|defined
Not quite.
At this moment, for any given class in a package, you can either have entries in the defined or in the extension dictionaries, but not in both in the same time. So, this is an indication that you can simply merge the two dictionaries.
sure but you have them to filter after.
As soon as you add a method to a package, you know exactly if that method is defined or not by knowing whether the class is defined in that package.
Yes this was the first implementation I did and it was boring to always check. Is the class defined or not.
Also, if you do have the methods in one dictionary, then you also won't have to care whether you moved the definition of a class between packages.
Ummm I do not buy that. How?
Right now, if you move the definition of a class without touching the methods, you will have to ensure in the two packages that the methods that were defined are not extensions and the other way around.
yes.
If you interpret the extension by looking at where the class is defined, then you do not lose anything.
speed? Indeed I could merge all the methods into two dictionaries instead of four and always check the classes defined in the packages. but I will be doing includes: all the time. I can give a try. May be I will do another implementation to be able to measure. I will first remove the isExtension:
Yet another point is that I typically first want to know the methods of a class from a package. I do not want to know which is extended or which is not. So, I currently have to look it up in two dictionaries which is not necessarily optimal.
you have the method methodForClass: for that, you get all the methods defined or extended for a class in a given package.
Or am I missing something?
On 17 March 2010 10:23, Lukas Renggli <renggli@gmail.com> wrote:
It tries to work with methods and classes through symbolic names.. and you immediately end up with gemmorage of a need to keep separate 'core' and 'extension' , 'meta' and 'instance-side' methods in your model.
Yes, that's what I suggested, merge the extension and core dictionaries.
I don't know what is the purpose of making a package to be a dead piece of flesh, which reflects own organization by using symbols, instead of real objects? Who are you trying to deceive with that?
Incremental development. Separation of concerns.
If the package would contain the real classes and real methods one had to change (literally) thousands of places in the system.
Hmm.. why is that? Currently everything in image is centered mainly around classes and methods & categories. And only a little around packages.
If you remember, i put some thoughts about packages here before. And even implemented a prototype package model myself (did you looked at it?). My concepts is simple and object-oriented (instead of symbolic-names oriented ;) ) :
Where?
There was a series of topics, One of them - 'System changes & security model' and then others where i tried to describe things a little more.
If we take a most abstract and stripped down concept then, in order to define a package, we need just two things: - a set of objects , which belong to that package - and a namespace (name->object), where name is a symbol and object is one of the objects, which belong to package.
RPackage is about a PackageInfo replacement, not about a namespace implementation. Arguably namespacing is something entirely different.
As i said, it doesn't implements a new model, but a different view on existing one. I envisioned a Package (real one) to replace a PackageInfo (hollow one). Like in attachment.
But if you don't that , you model will remain a piece of flesh, without skeleton - it can't move , it can only lie on the ground and rot :)
I suggested Stef to look at the environments in the refactoring engine. They are a proven implementation for more than 10 years, they work very efficiently with numerous GUIs (OB, VisualWorks, VisualAge), and have been applied in many different scenarios (introspection, reflection, refactorings, changes, lint, virtual code, ...).
I don't understand, why to not work with actual objects, instead of names? Please enlighten me, why you want to refer to objects indirectly and leaving to somethings else in the system to decide how these names turned into a real objects. What is the benefit of having such indirect model?
What would a method object refer to other than its class and its selector?
Err, what you mean by that? If a 'method object' is a method, then it should behave like a method - conform on a method's protocol. Isnt?
Is the introduction of another layer of objects that duplicates Class, PseudoClass, MCClassDefinition, RBClass and CompiledMethod, MethodReference, MCMethodDefinition, RBMethod reasonable?
I fail to see a whole point in having these symbolic referencing, instead of direct ones. If you need to turn a symbolic name into an object, you can always do it, when loading the code. Keeping them inside image after that serving no purpose.
Remember, this is just the internal implementation. I agree that to the outside a package should be represented using dedicated objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
If the package would contain the real classes and real methods one had to change (literally) thousands of places in the system.
Hmm.. why is that? Currently everything in image is centered mainly around classes and methods & categories. And only a little around packages.
How does the package know when a class is deleted? How does the package know when a class is deleted from within a #doSilently: block?
RPackage is about a PackageInfo replacement, not about a namespace implementation. Arguably namespacing is something entirely different.
As i said, it doesn't implements a new model, but a different view on existing one.
RPackage does not implement a different view: PackageInfo is implicit, it takes all information from elsewhere (category and protocol names). RPackage is explicit, it manages and knows its own contents.
Err, what you mean by that? If a 'method object' is a method, then it should behave like a method - conform on a method's protocol. Isnt?
The question is if you really want to store the real thing (compiled method)? RPackage chose to store a reference, because the real thing can easily and quickly be looked up. Package.st stores compiled methods in a large IdentitySet. Recompiling a method means that it need to be removed and re-added whenever something changes in the system. Somebody doing something in a #doSilently: block will immediately screw up your complete package model, because you suddenly miss methods or have different methods that are actually the same. Package.st does not seem practicable to build an efficient GUI. Having to iterate over the complete package contents to find certain elements is deadly to a responsive GUI. Getting the classes and methods must be a fast operation (ideally constant time) that does not depend on the number of elements in the package and the number of other packages. RPackage aims to answer questions a GUI might have quickly. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On 17 March 2010 11:46, Lukas Renggli <renggli@gmail.com> wrote:
If the package would contain the real classes and real methods one had to change (literally) thousands of places in the system.
Hmm.. why is that? Currently everything in image is centered mainly around classes and methods & categories. And only a little around packages.
How does the package know when a class is deleted?
Explicitly only! Because package is in control and should govern all of such operations: package remove: someclass. how do you removing a class from a system? Right: Smalltalk removeClassNamed: aName so, what is wrong with that?
How does the package know when a class is deleted from within a #doSilently: block?
this is irrelevant. Because if you build a system from a first principles, where a package is one of the key concepts in it, instead of a hollow abstraction, sure thing you taking care about all of it in proper manner.
RPackage is about a PackageInfo replacement, not about a namespace implementation. Arguably namespacing is something entirely different.
As i said, it doesn't implements a new model, but a different view on existing one.
RPackage does not implement a different view: PackageInfo is implicit, it takes all information from elsewhere (category and protocol names).
'Elsewhere' is a key word here, which means that PackageInfo is a view, and nothing more.
RPackage is explicit, it manages and knows its own contents.
Sure thing. In same way as i can write a brief description about something. But description of a subject cannot replace a subject itself. Because its missing a behavior and many other aspects.
Err, what you mean by that? If a 'method object' is a method, then it should behave like a method - conform on a method's protocol. Isnt?
The question is if you really want to store the real thing (compiled method)? RPackage chose to store a reference, because the real thing can easily and quickly be looked up.
Package.st stores compiled methods in a large IdentitySet. Recompiling a method means that it need to be removed and re-added whenever something changes in the system. Somebody doing something in a #doSilently: block will immediately screw up your complete package model, because you suddenly miss methods or have different methods that are actually the same.
you refer to a model, which doesn't takes this into account. Sure thing, it wont work. If you remember, i told about packages having policies, when any modification of a package, such as adding or changing a method, should go through package policy verification, and only then added to package, or rejected. This is what i think will be a cool thing. This is what i could easily implement with a new model. Now think how you could do that in yours. Another thing: your model allows only classes to be a real citizens of package. While with mine, i can export any object which belongs to a package, as long as it knows how to serialize/deserialize itself. This means that i can define named variables in scope of package, like: - Display, Sensor , World etc etc..
Package.st does not seem practicable to build an efficient GUI. Having to iterate over the complete package contents to find certain elements is deadly to a responsive GUI. Getting the classes and methods must be a fast operation (ideally constant time) that does not depend on the number of elements in the package and the number of other packages. RPackage aims to answer questions a GUI might have quickly.
It is not practicable because its not complete. Browser usually operating only with a small subset of a package - a class and its methods. I don't see how such organization could affect the performance. If you refer to things like #classes , compare mine: classes ^ contents select: [:object | object isBehavior and: [ object isMeta not] ] and the old PackageInfo: classes ^(self systemCategories gather: [:cat | (SystemOrganization listAtCategoryNamed: cat) collect: [:className | Smalltalk at: className]]) sortBy: [:a :b | a className <= b className] and you stating that mine will work slower? I really doubt that, given how things like #listAtCategoryNamed: implemented. And either way, at any time, i can add an inst var which will cache classes , if i would think this is not enough. Unless you want to generate a thousands lengthy lists in your tools. But then it is impractical from either side - users can't cope with such big amounts of information. And this is where we using an automated things for refactoring. But then, a performance in a mass-refactoring tools is not very relevant. -- Best regards, Igor Stasenko AKA sig.
Explicitly only! Because package is in control and should govern all of such operations:
package remove: someclass.
in my first implementation I got package removeClassFromSystem:.... but it implies too much changes. So the goal is now. Let us have real Package objects, support the transition with PackageInfo, support MC and do the next steps when the next steps is needed.
how do you removing a class from a system? Right:
Smalltalk removeClassNamed: aName
so, what is wrong with that?
How does the package know when a class is deleted from within a #doSilently: block?
this is irrelevant. Because if you build a system from a first principles, where a package is one of the key concepts in it, instead of a hollow abstraction, sure thing you taking care about all of it in proper manner.
but there are more urgent things to fix: network and others. So let us be incremental.
RPackage is explicit, it manages and knows its own contents.
Sure thing. In same way as i can write a brief description about something. But description of a subject cannot replace a subject itself. Because its missing a behavior and many other aspects.
the behavior of RPackage is to let know if a class is extended, which are its participants.
you refer to a model, which doesn't takes this into account. Sure thing, it wont work. If you remember, i told about packages having policies, when any modification of a package, such as adding or changing a method, should go through package policy verification, and only then added to package, or rejected. This is what i think will be a cool thing. This is what i could easily implement with a new model. Now think how you could do that in yours.
RPackage is not a namespace nor an hyper cool package system. It is a simple replacement of the bad packageInfo hack. Now just making sure replacement will take us a lot of energy and we will do it.
Another thing: your model allows only classes to be a real citizens of package. While with mine, i can export any object which belongs to a package, as long as it knows how to serialize/deserialize itself. This means that i can define named variables in scope of package, like: - Display, Sensor , World etc etc..
Good but this is not the purpose of RPackage. We need a good serializer in the future too.
It is not practicable because its not complete. Browser usually operating only with a small subset of a package - a class and its methods. I don't see how such organization could affect the performance.
If you refer to things like #classes , compare mine:
classes ^ contents select: [:object | object isBehavior and: [ object isMeta not] ]
and the old PackageInfo:
classes ^(self systemCategories gather: [:cat | (SystemOrganization listAtCategoryNamed: cat) collect: [:className | Smalltalk at: className]]) sortBy: [:a :b | a className <= b className]
and you stating that mine will work slower? I really doubt that, given how things like #listAtCategoryNamed: implemented.
We are not talking about the old packageInfo In RPackage classes ^ definedClasses :)
Unless you want to generate a thousands lengthy lists in your tools. But then it is impractical from either side - users can't cope with such big amounts of information. And this is where we using an automated things for refactoring. But then, a performance in a mass-refactoring tools is not very relevant.
It is with Moose PackageInfo nearly killed us we have to build a cache that takes 2 or 3 min to build before being able to work. Stef
Sorry, i was felt like you are at stage of 'making a first-class packages'. I understand that we going slowly to that, i just wanted to be sure that you doing right thing :) Sure, if RPackage is just an improved implementation of PackageInfo , i see nothing wrong with that. Thanks for listening my rants. :) On 17 March 2010 12:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Explicitly only! Because package is in control and should govern all of such operations:
package remove: someclass.
in my first implementation I got package removeClassFromSystem:....
but it implies too much changes. So the goal is now. Let us have real Package objects, support the transition with PackageInfo, support MC and do the next steps when the next steps is needed.
how do you removing a class from a system? Right:
Smalltalk removeClassNamed: aName
so, what is wrong with that?
How does the package know when a class is deleted from within a #doSilently: block?
this is irrelevant. Because if you build a system from a first principles, where a package is one of the key concepts in it, instead of a hollow abstraction, sure thing you taking care about all of it in proper manner.
but there are more urgent things to fix: network and others. So let us be incremental.
RPackage is explicit, it manages and knows its own contents.
Sure thing. In same way as i can write a brief description about something. But description of a subject cannot replace a subject itself. Because its missing a behavior and many other aspects.
the behavior of RPackage is to let know if a class is extended, which are its participants.
you refer to a model, which doesn't takes this into account. Sure thing, it wont work. If you remember, Â i told about packages having policies, when any modification of a package, such as adding or changing a method, should go through package policy verification, and only then added to package, or rejected. This is what i think will be a cool thing. This is what i could easily implement with a new model. Now think how you could do that in yours.
RPackage is not a namespace nor an hyper cool package system. It is a simple replacement of the bad packageInfo hack. Now just making sure replacement will take us a lot of energy and we will do it.
Another thing: your model allows only classes to be a real citizens of package. While with mine, i can export any object which belongs to a package, as long as it knows how to serialize/deserialize itself. This means that i can define named variables in scope of package, like: - Display, Sensor , World etc etc..
Good but this is not the purpose of RPackage. We need a good serializer in the future too.
It is not practicable because its not complete. Browser usually operating only with a small subset of a package - a class and its methods. I don't see how such organization could affect the performance.
If you refer to things like #classes , compare mine:
classes    ^ contents select: [:object | object isBehavior and: [ object isMeta not] ]
and the old PackageInfo:
classes    ^(self systemCategories gather:        [:cat |        (SystemOrganization listAtCategoryNamed: cat)            collect: [:className | Smalltalk at: className]])                sortBy: [:a :b | a className <= b className]
and you stating that mine will work slower? I really doubt that, given how things like #listAtCategoryNamed: implemented.
We are not talking about the old packageInfo
In RPackage     classes         ^ definedClasses
:)
Unless you want to generate a thousands lengthy lists in your tools. But then it is impractical from either side - users can't cope with such big amounts of information. And this is where we using an automated things for refactoring. But then, a performance in a mass-refactoring tools is not very relevant.
It is with Moose PackageInfo nearly killed us we have to build a cache that takes 2 or 3 min to build before being able to work.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Mar 17, 2010, at 11:52 AM, Igor Stasenko wrote:
Sorry, i was felt like you are at stage of 'making a first-class packages'.
this is a first class package but not a module system nor a namespace. Stef
I understand that we going slowly to that, i just wanted to be sure that you doing right thing :) Sure, if RPackage is just an improved implementation of PackageInfo , i see nothing wrong with that.
Thanks for listening my rants. :)
On 17 March 2010 12:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Explicitly only! Because package is in control and should govern all of such operations:
package remove: someclass.
in my first implementation I got package removeClassFromSystem:....
but it implies too much changes. So the goal is now. Let us have real Package objects, support the transition with PackageInfo, support MC and do the next steps when the next steps is needed.
how do you removing a class from a system? Right:
Smalltalk removeClassNamed: aName
so, what is wrong with that?
How does the package know when a class is deleted from within a #doSilently: block?
this is irrelevant. Because if you build a system from a first principles, where a package is one of the key concepts in it, instead of a hollow abstraction, sure thing you taking care about all of it in proper manner.
but there are more urgent things to fix: network and others. So let us be incremental.
RPackage is explicit, it manages and knows its own contents.
Sure thing. In same way as i can write a brief description about something. But description of a subject cannot replace a subject itself. Because its missing a behavior and many other aspects.
the behavior of RPackage is to let know if a class is extended, which are its participants.
you refer to a model, which doesn't takes this into account. Sure thing, it wont work. If you remember, i told about packages having policies, when any modification of a package, such as adding or changing a method, should go through package policy verification, and only then added to package, or rejected. This is what i think will be a cool thing. This is what i could easily implement with a new model. Now think how you could do that in yours.
RPackage is not a namespace nor an hyper cool package system. It is a simple replacement of the bad packageInfo hack. Now just making sure replacement will take us a lot of energy and we will do it.
Another thing: your model allows only classes to be a real citizens of package. While with mine, i can export any object which belongs to a package, as long as it knows how to serialize/deserialize itself. This means that i can define named variables in scope of package, like: - Display, Sensor , World etc etc..
Good but this is not the purpose of RPackage. We need a good serializer in the future too.
It is not practicable because its not complete. Browser usually operating only with a small subset of a package - a class and its methods. I don't see how such organization could affect the performance.
If you refer to things like #classes , compare mine:
classes ^ contents select: [:object | object isBehavior and: [ object isMeta not] ]
and the old PackageInfo:
classes ^(self systemCategories gather: [:cat | (SystemOrganization listAtCategoryNamed: cat) collect: [:className | Smalltalk at: className]]) sortBy: [:a :b | a className <= b className]
and you stating that mine will work slower? I really doubt that, given how things like #listAtCategoryNamed: implemented.
We are not talking about the old packageInfo
In RPackage classes ^ definedClasses
:)
Unless you want to generate a thousands lengthy lists in your tools. But then it is impractical from either side - users can't cope with such big amounts of information. And this is where we using an automated things for refactoring. But then, a performance in a mass-refactoring tools is not very relevant.
It is with Moose PackageInfo nearly killed us we have to build a cache that takes 2 or 3 min to build before being able to work.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mar 17, 2010, at 11:23 15AM, Igor Stasenko wrote:
How does the package know when a class is deleted from within a #doSilently: block?
this is irrelevant. Because if you build a system from a first principles, where a package is one of the key concepts in it, instead of a hollow abstraction, sure thing you taking care about all of it in proper manner.
RPackage is about a PackageInfo replacement, not about a namespace implementation. Arguably namespacing is something entirely different.
As i said, it doesn't implements a new model, but a different view on existing one.
RPackage does not implement a different view: PackageInfo is implicit, it takes all information from elsewhere (category and protocol names).
'Elsewhere' is a key word here, which means that PackageInfo is a view, and nothing more.
Yes, you are talking about two entirely different kinds of Package. RPackage is, like PackageInfo, just a view of the underlying system, but maintaining a cache of the essential data instead of recomputing at every message send. Cheers, Henry
RPackage is, like PackageInfo, just a view of the underlying system, but maintaining a cache of the essential data instead of recomputing at every message send.
No, this is not true. RPackage does not have a cache. Please, have a look at the code. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On 17 March 2010 12:45, Lukas Renggli <renggli@gmail.com> wrote:
RPackage is, like PackageInfo, just a view of the underlying system, but maintaining a cache of the essential data instead of recomputing at every message send.
No, this is not true. RPackage does not have a cache. Please, have a look at the code.
Strongly speaking, it is a cache, because you can recreate a full package info by searching through different places in system. This is a main difference to what i have proposed, i think.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On 17 March 2010 12:54, Igor Stasenko <siguctua@gmail.com> wrote:
On 17 March 2010 12:45, Lukas Renggli <renggli@gmail.com> wrote:
RPackage is, like PackageInfo, just a view of the underlying system, but maintaining a cache of the essential data instead of recomputing at every message send.
No, this is not true. RPackage does not have a cache. Please, have a look at the code.
Strongly speaking, it is a cache, because you can recreate a full i meant 'strictly speaking'. Sorry, my english fails me sometimes :)
package info by searching through different places in system. This is a main difference to what i have proposed, i think.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
No, this is not true. RPackage does not have a cache. Please, have a look at the code.
Strongly speaking, it is a cache, because you can recreate a full package info by searching through different places in system. This is a main difference to what i have proposed, i think.
Only if you keep the category and protocols up-to-date with all operations. I don't think that this is done/planned with RPackage. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Explicitly only! Because package is in control and should govern all of such operations:
package remove: someclass.
how do you removing a class from a system? Right:
Smalltalk removeClassNamed: aName
so, what is wrong with that?
Nothing is wrong. It sounds great, but unfortunately we have an existing system that doesn't work like this. And big-bang changes like you propose don't work. There will be thousands of lines of code to be adapted in the image and in external packages.
How does the package know when a class is deleted from within a #doSilently: block?
this is irrelevant. Because if you build a system from a first principles, where a package is one of the key concepts in it, instead of a hollow abstraction, sure thing you taking care about all of it in proper manner.
Yes, but we don't build a new system. We fix and improve an existing one.
RPackage is about a PackageInfo replacement, not about a namespace implementation. Arguably namespacing is something entirely different.
As i said, it doesn't implements a new model, but a different view on existing one.
RPackage does not implement a different view: PackageInfo is implicit, it takes all information from elsewhere (category and protocol names).
'Elsewhere' is a key word here, which means that PackageInfo  is a view, and nothing more.
Yes, PackageInfo is a view. I am just saying that RPackage is not a view.
Another thing: your model allows only classes to be a real citizens of package. While with mine, i can export any object which belongs to a package, as long as it knows how to serialize/deserialize itself. This means that i can define named variables in scope of package, like: Â - Display, Sensor , World etc etc..
The question is if we really want to have that. You're proposal seems to try to solve too many problems: packaging, namespaces, import, export, serialization, ... RPackage aims to solve one thing only, packaging.
If you refer to things like #classes , compare mine:
classes     ^ contents select: [:object | object isBehavior and: [ object isMeta not] ]
and the old PackageInfo:
classes     ^(self systemCategories gather:         [:cat |         (SystemOrganization listAtCategoryNamed: cat)             collect: [:className | Smalltalk at: className]])                 sortBy: [:a :b | a className <= b className]
and you stating that mine will work slower?
I am not talking about PackageInfo. I think we agree that PackageInfo is not ideal. What I am saying is that Package.st is no better than PackageInfo, because it iterates over a large set of objects to select the interesting parts. That slows tools down. RPackage has a structural model and can return the classes without having to filter.
Unless you want to generate a thousands lengthy lists in your tools. But then it is impractical from either side - users can't cope with such big amounts of information.
You need to be able to generate thousands of (small) lists for classes, protocols and methods when you for example scroll through a package tree. Select a package in O2 or a category in OB and scroll down using the down arrow to see what I mean. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Mar 17, 2010, at 8:32 AM, Igor Stasenko wrote:
Hi Stef,
i took a look on your implementation and i don't like it. :)
Ok fair My first implementation was holding classes and objects and people did not like it either.
It tries to work with methods and classes through symbolic names..
The first implementation was only holding classes and compiled methods/methodreferences and the problems is that you cannot reason about off-line system. Lukas told me ok this is not good because of that. Look at RBEnvironment. So I rewrote everything 3 times. So I'm started to get bored.
I don't know what is the purpose of making a package to be a dead piece of flesh, which reflects own organization by using symbols, instead of real objects? Who are you trying to deceive with that?
Off image package manipulation.
If you remember, i put some thoughts about packages here before. And even implemented a prototype package model myself (did you looked at it?).
Now where is the code? What is the cost to find all the extendingClasses, if a method is included in a packages, classes extensions, how do we hook event for classremoval, classaddition, without raising multiple times the same.
My concepts is simple and object-oriented (instead of symbolic-names oriented ;) ) : If we take a most abstract and stripped down concept then, in order to define a package, we need just two things: - a set of objects , which belong to that package - and a namespace (name->object), where name is a symbol and object is one of the objects, which belong to package.
note, that there is no any 'methods' or 'classes' . It is just objects and names. And then you can start adding flesh on that skeleton by implementing things , like covenient adding/defining/lookup classes, methods , etc etc. But if you don't that , you model will remain a piece of flesh, without skeleton - it can't move , it can only lie on the ground and rot :)
I don't understand, why to not work with actual objects, instead of names? Please enlighten me, why you want to refer to objects indirectly and leaving to somethings else in the system to decide how these names turned into a real objects. What is the benefit of having such indirect model?
We could create package and manipulate them even if they are not in the image.
In such form, a package becomes only a view of something which already exists in a system without it. It doesn't defining a domain space - just reflecting existing one (a years-old existing system organization (classes and methods)).
Exactly. But if you want to introduce Package then a method should know its package (which I did in my first implementation).
And thus, you will have a hard times when you would want to migrate to a new system organization, because all levers of control lying elsewhere, instead in a package itself.
Did not get this one.
On 16 March 2010 18:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok.
Now I would really like if - somebody could have a look at the code - develop a simple package browser showing class extensions (it would help me to define a good api to walk though a package). I started to use Momo and this is why I reimplemented the class but so far I get nearly the same interface and I think that I can do better.
Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far - integration with MC - migrating from packageInfo - event notification are missing.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 17 March 2010 10:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Mar 17, 2010, at 8:32 AM, Igor Stasenko wrote:
Hi Stef,
i took a look on your implementation and i don't like it. :)
Ok fair My first implementation was holding classes and objects and people did not like it either.
It tries to work with methods and classes through symbolic names..
The first implementation was only holding classes and compiled methods/methodreferences and the problems is that you cannot reason about off-line system.
It sounds like you can reason about contents of an image file if you open it in a text editor or hex dump.
Lukas told me ok this is not good because of that. Look at RBEnvironment. So I rewrote everything 3 times. So I'm started to get bored.
So, looks like i am little late in the game.. Too bad.
I don't know what is the purpose of making a package to be a dead piece of flesh, which reflects own organization by using symbols, instead of real objects? Who are you trying to deceive with that?
Off image package manipulation.
I fail to see how this is relevant to a in-image representation. I can choose any file-out/in format i want - binary, xml, .st , whatever... So, i really don't understand what you talking about 'off-line' here.
If you remember, i put some thoughts about packages here before. And even implemented a prototype package model myself (did you looked at it?).
Now where is the code?
Strange, i thought i shown it before.. i could send it to you if you want. I remember i presented most of my ideas & concerns about this couple months ago, and we did talked about it.
What is the cost to find all the extendingClasses, if a method is included in a packages, classes extensions, how do we hook event for classremoval, classaddition, without raising multiple times the same.
In a properly implemented system it will be same or less. Because model is same, since you refer to same object(s), having same structural organization. So why it should be any slower?
My concepts is simple and object-oriented (instead of symbolic-names oriented ;) ) : If we take a most abstract and stripped down concept then, in order to define a package, we need just two things: - a set of objects , which belong to that package - and a namespace (name->object), where name is a symbol and object is one of the objects, which belong to package.
note, that there is no any 'methods' or 'classes' . It is just objects and names. And then you can start adding flesh on that skeleton by implementing things , like covenient adding/defining/lookup classes, methods , etc etc. But if you don't that , you model will remain a piece of flesh, without skeleton - it can't move , it can only lie on the ground and rot :)
I don't understand, why to not work with actual objects, instead of names? Please enlighten me, why you want to refer to objects indirectly and leaving to somethings else in the system to decide how these names turned into a real objects. What is the benefit of having such indirect model?
We could create package and manipulate them even if they are not in the image.
same as above about 'offline'... what you mean by manipulating something which lives and having a flesh only if it runs inside an image?
In such form, a package becomes only a view of something which already exists in a system without it. It doesn't defining a domain space - just reflecting existing one (a years-old existing system organization (classes and methods)).
Exactly. But if you want to introduce Package then a method should know its package (which I did in my first implementation).
Indeed, or reversely - a package knows what methods belonging to it. Take a look at ClassOrganizer it using similar approach. A method doesn't knows to what category it belongs to. But still, tools are able to determine that. Except that , again a ClassOrganizer refers to methods indirectly, through 'selectors', like selectors have anything to do with behavior , which is any compiled method holding. Or maybe this is what you talking about 'manipulating offline'? You can file out class name and selectors it contains. Now you can manipulate with these names... for no purpose, because you missing a key thing which makes all of these names reason to exist - a behavior and data:) We saying 'each method of class belongs to a certain category'. This means that there are relation between category name and a method. The question is where to put that relation - you can either add a 'category' or 'categories' field to a compiled method and you done or start building a mess.
And thus, you will have a hard times when you would want to migrate to a new system organization, because all levers of control lying elsewhere, instead in a package itself.
Did not get this one.
ClassOrganizer is your guide. ;)
-- Best regards, Igor Stasenko AKA sig.
I fail to see how this is relevant to a in-image representation. I can choose any file-out/in format i want - binary, xml, .st , whatever... So, i really don't understand what you talking about 'off-line' here.
Because we could browse squeaksource mc file using the same browser. Just need to have the representation. Lukas pointed to the problems if we go for real living objects we will have to pay attention to a lot of places and may be this is something to do in a second step. I would prefer to have classes and methods but this is more brittle. Stef
On 17 March 2010 12:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I fail to see how this is relevant to a in-image representation. I can choose any file-out/in format i want - binary, xml, .st , whatever... So, i really don't understand what you talking about 'off-line' here.
Because we could browse squeaksource mc file using the same browser. Just need to have the representation.
Ah, i see. And what about it? Instantiate a class object an put everything you need there. You can avoid compiling methods, but put a 'NotYetLoadedMethod' instances into its dict. Look, i can do similar things to what is MethodReference or PseudoClass is used for in current implementation, means that instead of reifying a real object, put a proxies to unreal ones. And then you can browse it and do same things. Where is the problem?
Lukas pointed to the problems if we go for real living objects we will have to pay attention to a lot of places and may be this is something to do in a second step.
Right. Introducing my idea will require a lot of changes in various places. So, if your only argument, that we're not ready for it yet, i accepting that :)
I would prefer to have classes and methods but this is more brittle.
Nope. Explicit control is always less brittle than implicit.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (5)
-
Henrik Johansen -
Igor Stasenko -
Lukas Renggli -
Stéphane Ducasse -
Tudor Girba