[Pharo-project] Plugin organization
Hi all, while working on a new (Open)Sophie release I ran into the problem of where to put some plugin code. In this case it is for the Curl Plugin, which Steven Riggins ported into Sophie, but the problem is pretty common I would guess. So the problem is this (as illustrated using our Curl package): - we have a package Sophie-Curl, which includes the Squeak Curl client and the CurlPlugin class. - loaded into a "normal" image, the CurlPlugin ends up being a subclass of ProtObject as the superclass is missing. - now we separate it into Sophie-Curl and Sophie-Curl-Plugin, but that won't fly with the MC name matching - so we name it Sophie-Curl and Sophie-Plugin-Curl I think that is ugly. What I would like to propose is that we organize all plugins in Pharo in to a Plugin category. So we would then have "Plugin-Curl", "Plugin-Locale" etc. Or alternatively "Plugin-Network-Curl", "Plugin-System-Locale" etc. That would also allow to simply load all plugins into a VMMaker image by using a package "Plugin". What do you guys think? Michael
sounds good to my eyes. regularity is a huge plus to my eyes. I would like to have patterns to organize tests too. We should keep our braincells for real problems. On Jan 21, 2009, at 2:05 PM, Michael Rueger wrote:
Hi all,
while working on a new (Open)Sophie release I ran into the problem of where to put some plugin code. In this case it is for the Curl Plugin, which Steven Riggins ported into Sophie, but the problem is pretty common I would guess.
So the problem is this (as illustrated using our Curl package):
- we have a package Sophie-Curl, which includes the Squeak Curl client and the CurlPlugin class. - loaded into a "normal" image, the CurlPlugin ends up being a subclass of ProtObject as the superclass is missing. - now we separate it into Sophie-Curl and Sophie-Curl-Plugin, but that won't fly with the MC name matching - so we name it Sophie-Curl and Sophie-Plugin-Curl
I think that is ugly.
What I would like to propose is that we organize all plugins in Pharo in to a Plugin category. So we would then have "Plugin-Curl", "Plugin-Locale" etc. Or alternatively "Plugin-Network-Curl", "Plugin-System-Locale" etc.
That would also allow to simply load all plugins into a VMMaker image by using a package "Plugin".
What do you guys think?
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Michael Rueger writes:
Hi all,
while working on a new (Open)Sophie release I ran into the problem of where to put some plugin code. In this case it is for the Curl Plugin, which Steven Riggins ported into Sophie, but the problem is pretty common I would guess.
So the problem is this (as illustrated using our Curl package):
- we have a package Sophie-Curl, which includes the Squeak Curl client and the CurlPlugin class. - loaded into a "normal" image, the CurlPlugin ends up being a subclass of ProtObject as the superclass is missing. - now we separate it into Sophie-Curl and Sophie-Curl-Plugin, but that won't fly with the MC name matching - so we name it Sophie-Curl and Sophie-Plugin-Curl
I think that is ugly.
What I would like to propose is that we organize all plugins in Pharo in to a Plugin category. So we would then have "Plugin-Curl", "Plugin-Locale" etc. Or alternatively "Plugin-Network-Curl", "Plugin-System-Locale" etc.
That would also allow to simply load all plugins into a VMMaker image by using a package "Plugin".
What do you guys think?
Why not just add the plugin's to the VMMaker package? I don't see any gain for having another official plugin package besides VMMaker. It'll have the main problem and advantage of VMMaker of central ownership. Having a Universes package that builds a standard VM building image would be a useful step forward. The packages for all standard Pharo packages could be included automatically. I'm doing something like this with the exupery-dev Universes package, just remove the Exupery elements if you're not interested in that. Bryce
bryce@kampjes.demon.co.uk wrote:
Why not just add the plugin's to the VMMaker package?
I don't see any gain for having another official plugin package besides VMMaker. It'll have the main problem and advantage of VMMaker of central ownership.
That's not what I suggested, just a naming scheme. I also don't think that all plugins will be centrally maintained, as that would require write access of every plugin maintainer to the VM repository. Michael
Michael Rueger writes:
bryce@kampjes.demon.co.uk wrote:
Why not just add the plugin's to the VMMaker package?
I don't see any gain for having another official plugin package besides VMMaker. It'll have the main problem and advantage of VMMaker of central ownership.
That's not what I suggested, just a naming scheme.
I also don't think that all plugins will be centrally maintained, as that would require write access of every plugin maintainer to the VM repository.
Michael
But Monticello packages are just a naming scheme. Your statement: "That would also allow to simply load all plugins into a VMMaker image by using a package 'Plugin'.". Seems to indicate to me that using the naming convention you suggested would lead to all the packages being part of a single Monticello package. Bryce
bryce@kampjes.demon.co.uk wrote:
But Monticello packages are just a naming scheme.
yes and no. A package is defined using the name and string matching, but a package is a package.
Your statement: "That would also allow to simply load all plugins into a VMMaker image by using a package 'Plugin'.". Seems to indicate to me that using the naming convention you suggested would lead to all the packages being part of a single Monticello package.
Hmm, yes and no again ;-) But I now I see what you are saying... Being able to load all plugin packages by defining a "meta" package "Plugin" exploits the string matching nature of Monticello. This "meta" package would be simply a convenience for loading, it should not, or rather must not, be stored, ever. Anyways, my proposal was really more about a naming convention for Plugin packages. The same convention could also be applied to test packages btw to avoid all this very "creative" naming, patching the "test" somewhere into the category name. Michael
On Jan 30, 2009, a
The same convention could also be applied to test packages btw to avoid all this very "creative" naming, patching the "test" somewhere into the category name.
YES so what are the organizations we can use? Ideally I would like to have the test associated with their packages. XXX XXXTests but may be people found a better way Stef
Stéphane Ducasse wrote:
so what are the organizations we can use? Ideally I would like to have the test associated with their packages.
XXX XXXTests
The problem with that naming scheme is that then the tests would always be loaded together with their tests because of the simple string matching Monticello does. Which isn't something you want when doing application/runtime builds. That's why I proposed the Plugin-* and Tests-* naming schemes. Michael
so what are the organizations we can use? Ideally I would like to have the test associated with their packages.
XXX XXXTests
but may be people found a better way
That doesn't work, because you end up with overlapping package names. This is how we name packages in Seaside 2.9: http://code.google.com/p/seaside/wiki/PackageNaming Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Jan 30, 2009, at 15:33 , Michael Rueger wrote:
Stéphane Ducasse wrote:
so what are the organizations we can use? Ideally I would like to have the test associated with their packages.
XXX XXXTests
The problem with that naming scheme is that then the tests would always be loaded together with their tests because of the simple string matching Monticello does. Which isn't something you want when doing application/runtime builds.
That's why I proposed the Plugin-* and Tests-* naming schemes.
+1 Adrian
Ok so do we following the seaside way or the other? Once we get decided I will do a pass and be compliant :) Stef
On Jan 30, 2009, at 15:33 , Michael Rueger wrote:
Stéphane Ducasse wrote:
so what are the organizations we can use? Ideally I would like to have the test associated with their packages.
XXX XXXTests
The problem with that naming scheme is that then the tests would always be loaded together with their tests because of the simple string matching Monticello does. Which isn't something you want when doing application/runtime builds.
That's why I proposed the Plugin-* and Tests-* naming schemes.
+1
Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I like the seaside organization Top-(Purpose-)(Platform-)Rest * Seaside-Canvas contains he canvas implementation. * Seaside-Squeak-Canvas contains the platform specific code of the canvas implementation. * Seaside-Examples-Canvas contains example code showing off the canvas implementation. * Seaside-Tests-Canvas contains the tests for the canvas implementation. * Seaside-Tests-Squeak-Canvas contains the platform specific tests of the canvas implementation. On Jan 30, 2009, at 3:54 PM, Adrian Lienhard wrote:
On Jan 30, 2009, at 15:33 , Michael Rueger wrote:
Stéphane Ducasse wrote:
so what are the organizations we can use? Ideally I would like to have the test associated with their packages.
XXX XXXTests
The problem with that naming scheme is that then the tests would always be loaded together with their tests because of the simple string matching Monticello does. Which isn't something you want when doing application/runtime builds.
That's why I proposed the Plugin-* and Tests-* naming schemes.
+1
Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, Jan 21, 2009 at 02:05:46PM +0100, Michael Rueger wrote: m Hi all,
What I would like to propose is that we organize all plugins in Pharo in to a Plugin category. So we would then have "Plugin-Curl", "Plugin-Locale" etc. Or alternatively "Plugin-Network-Curl", "Plugin-System-Locale" etc.
That would also allow to simply load all plugins into a VMMaker image by using a package "Plugin".
What do you guys think?
+1 on a common naming convention for this. I would also like to suggest something to distinguish VM plugins from other kinds of "plugins". The reason is that the word "Plugin" is used to describe the web browser plugin, and maybe other things in the future. If we say "VmPlugin" or "VMConstruction-Plugin-* then the difference is clear. I checked an older Squeak image to remind myself of the original naming convention, which was: VMConstruction-Interpreter VMConstruction-Translation VMConstruction-Plugins VMConstruction-B3DSimulation VMConstruction-TestPlugins VMConstruction-Applescript Some older plugins that are maintained outside of the VMMaker package already use this package naming convention, hence: VMConstruction-Plugins-OSProcessPlugin VMConstruction-Plugins-XDisplayControlPlugin VMConstruction-Plugins-AioPlugin This still looks perfectly good to me, so how about just using "VMConstruction-Plugins-*" rather than "Plugins-*"? Michael Rueger proposed Plugin-* and Tests-*, so guess that this would be: VMConstruction-Plugins VMConstruction-Tests or is it "Tests-VMConstruction-Plugins" ?? I am not sure. (cc to vm-dev list) Dave
I would like to use the seaside convention so is it ok for you? Then I will proceed and rename eveyrthing. stef On Jan 31, 2009, at 10:51 AM, Stéphane Ducasse wrote:
I like the seaside organization
Top-(Purpose-)(Platform-)Rest
* Seaside-Canvas contains he canvas implementation. * Seaside-Squeak-Canvas contains the platform specific code of the canvas implementation. * Seaside-Examples-Canvas contains example code showing off the canvas implementation. * Seaside-Tests-Canvas contains the tests for the canvas implementation. * Seaside-Tests-Squeak-Canvas contains the platform specific tests of the canvas implementation.
On Jan 30, 2009, at 3:54 PM, Adrian Lienhard wrote:
On Jan 30, 2009, at 15:33 , Michael Rueger wrote:
Stéphane Ducasse wrote:
so what are the organizations we can use? Ideally I would like to have the test associated with their packages.
XXX XXXTests
The problem with that naming scheme is that then the tests would always be loaded together with their tests because of the simple string matching Monticello does. Which isn't something you want when doing application/runtime builds.
That's why I proposed the Plugin-* and Tests-* naming schemes.
+1
Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Stef, On Feb 7, 2009, at 14:40 , Stéphane Ducasse wrote:
I would like to use the seaside convention so is it ok for you? Then I will proceed and rename eveyrthing.
What would be the resulting packages? I.e., how would you map the Top and Rest parts to the existing structure we have? I think that decision should be well considered as it has quite some impact (e.g., on the number of class categories and packages). I discussed with Lukas about the Seaside packaging scheme documented at http://code.google.com/p/seaside/wiki/PackageNaming The conclusion was that for Pharo the top level and the Platform level may not make much sense and could be left out. Then we would have a scheme like (Purpose-)Rest where Purpose = Tests, Examples, .. Rest = Kernel, Collections, Network, ... Note that this is the *package* structure (what you see in MC), not the class category structure. The latter could be more fine grained at the lower level (e.g., Tools-Debugger, Tools-Inspector, ... as it is structured now). The consequence would be that we have packages like Kernel Collections Tools ... Tests-Kernel Tests-Collections Tests-Tools I'm not convinced that this is the right structure, though, as we end up with lots of Test-xyz packages. As an alternative, I can imagine the package scheme Top-Rest where we have a very coarse grained Top level. For instance, we would have the following Top items: Kernel Graphics Libraries Tools Tests This means, we would have packages like Kernel-Numbers Kernel-Traits Kernel-Compiler ... Libraries-Collections Libraries-Regex Libraries-Network ... Tests-Kernel Tests-Libraries ... I'm curious if there are other ideas around. One way or the other, we need to clean this up. Right now it is a mess. E.g., there is a top level package MethodFinder, while all other tools are in the Tools package. Cheers, Adrian
stef
On Jan 31, 2009, at 10:51 AM, Stéphane Ducasse wrote:
I like the seaside organization
Top-(Purpose-)(Platform-)Rest
* Seaside-Canvas contains he canvas implementation. * Seaside-Squeak-Canvas contains the platform specific code of the canvas implementation. * Seaside-Examples-Canvas contains example code showing off the canvas implementation. * Seaside-Tests-Canvas contains the tests for the canvas implementation. * Seaside-Tests-Squeak-Canvas contains the platform specific tests of the canvas implementation.
On Jan 30, 2009, at 3:54 PM, Adrian Lienhard wrote:
On Jan 30, 2009, at 15:33 , Michael Rueger wrote:
Stéphane Ducasse wrote:
so what are the organizations we can use? Ideally I would like to have the test associated with their packages.
XXX XXXTests
The problem with that naming scheme is that then the tests would always be loaded together with their tests because of the simple string matching Monticello does. Which isn't something you want when doing application/runtime builds.
That's why I proposed the Plugin-* and Tests-* naming schemes.
+1
Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
When I mentioned Seaside I was not thinking explicitly in terms of Top- Purpose... What I like is that you have package but you have a kind of modules = object-oriented I would like to have Collections-Kernel Collections-Kernel-Tests Collections-Arrayed Collections-Arrayed-Tests Network-Kernel Network-Kernel-Tests ... So that I can get all the packages with their tests if I want. Also when I browse the package I see the tests and the other points grouped togethe
(Purpose-)Rest
where
Purpose = Tests, Examples, .. Rest = Kernel, Collections, Network, ...
Note that this is the *package* structure (what you see in MC), not the class category structure. The latter could be more fine grained at the lower level (e.g., Tools-Debugger, Tools-Inspector, ... as it is structured now).
The consequence would be that we have packages like
Kernel Collections Tools ... Tests-Kernel Tests-Collections Tests-Tools
I'm not convinced that this is the right structure, though, as we end up with lots of Test-xyz packages.
As an alternative, I can imagine the package scheme
Top-Rest
where we have a very coarse grained Top level. For instance, we would have the following Top items:
Kernel Graphics Libraries Tools Tests
This means, we would have packages like
Kernel-Numbers Kernel-Traits Kernel-Compiler ... Libraries-Collections Libraries-Regex Libraries-Network ... Tests-Kernel Tests-Libraries ...
I'm curious if there are other ideas around. One way or the other, we need to clean this up. Right now it is a mess. E.g., there is a top level package MethodFinder, while all other tools are in the Tools package.
INdEeD :)
Cheers, Adrian
stef
On Jan 31, 2009, at 10:51 AM, Stéphane Ducasse wrote:
I like the seaside organization
Top-(Purpose-)(Platform-)Rest
* Seaside-Canvas contains he canvas implementation. * Seaside-Squeak-Canvas contains the platform specific code of the canvas implementation. * Seaside-Examples-Canvas contains example code showing off the canvas implementation. * Seaside-Tests-Canvas contains the tests for the canvas implementation. * Seaside-Tests-Squeak-Canvas contains the platform specific tests of the canvas implementation.
On Jan 30, 2009, at 3:54 PM, Adrian Lienhard wrote:
On Jan 30, 2009, at 15:33 , Michael Rueger wrote:
Stéphane Ducasse wrote:
so what are the organizations we can use? Ideally I would like to have the test associated with their packages.
XXX XXXTests
The problem with that naming scheme is that then the tests would always be loaded together with their tests because of the simple string matching Monticello does. Which isn't something you want when doing application/runtime builds.
That's why I proposed the Plugin-* and Tests-* naming schemes.
+1
Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
nonono ;-) See earlier mails in this thread, this way you end up with the tests stored in the core package because e.g. Collections-Kernel also matches Collections-Kernel-Tests. michael On Tue, Feb 10, 2009 at 7:43 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
When I mentioned Seaside I was not thinking explicitly in terms of Top- Purpose...
What I like is that you have package but you have a kind of modules = object-oriented I would like to have
Collections-Kernel Collections-Kernel-Tests Collections-Arrayed Collections-Arrayed-Tests
Network-Kernel Network-Kernel-Tests ...
So that I can get all the packages with their tests if I want. Also when I browse the package I see the tests and the other points grouped togethe
(Purpose-)Rest
where
Purpose = Tests, Examples, .. Rest = Kernel, Collections, Network, ...
Note that this is the *package* structure (what you see in MC), not the class category structure. The latter could be more fine grained at the lower level (e.g., Tools-Debugger, Tools-Inspector, ... as it is structured now).
The consequence would be that we have packages like
Kernel Collections Tools ... Tests-Kernel Tests-Collections Tests-Tools
I'm not convinced that this is the right structure, though, as we end up with lots of Test-xyz packages.
As an alternative, I can imagine the package scheme
Top-Rest
where we have a very coarse grained Top level. For instance, we would have the following Top items:
Kernel Graphics Libraries Tools Tests
This means, we would have packages like
Kernel-Numbers Kernel-Traits Kernel-Compiler ... Libraries-Collections Libraries-Regex Libraries-Network ... Tests-Kernel Tests-Libraries ...
I'm curious if there are other ideas around. One way or the other, we need to clean this up. Right now it is a mess. E.g., there is a top level package MethodFinder, while all other tools are in the Tools package.
INdEeD
:)
Cheers, Adrian
stef
On Jan 31, 2009, at 10:51 AM, Stéphane Ducasse wrote:
I like the seaside organization
Top-(Purpose-)(Platform-)Rest
* Seaside-Canvas contains he canvas implementation. * Seaside-Squeak-Canvas contains the platform specific code of the canvas implementation. * Seaside-Examples-Canvas contains example code showing off the canvas implementation. * Seaside-Tests-Canvas contains the tests for the canvas implementation. * Seaside-Tests-Squeak-Canvas contains the platform specific tests of the canvas implementation.
On Jan 30, 2009, at 3:54 PM, Adrian Lienhard wrote:
On Jan 30, 2009, at 15:33 , Michael Rueger wrote:
Stéphane Ducasse wrote:
so what are the organizations we can use? Ideally I would like to have the test associated with their packages.
XXX XXXTests
The problem with that naming scheme is that then the tests would always be loaded together with their tests because of the simple string matching Monticello does. Which isn't something you want when doing application/runtime builds.
That's why I proposed the Plugin-* and Tests-* naming schemes.
+1
Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
nonono ;-) See earlier mails in this thread, this way you end up with the tests stored in the core package because e.g. Collections-Kernel also matches Collections-Kernel-Tests.
Is it a bad thing? <beReadyToShot> To that extend, I was wondering why we have the TestCase class. Ideally, I would like to have all the test methods coming along with the domain. As I have for documentation and comment. When I browse Lukas' code, the complete class hierarchy in the domain is duplicated in the tests. When we wrote the tests of the collection, we duplicated even method categories! With all that said, feel free to shot :-) </beReadyToShot > Alexandre
michael
On Tue, Feb 10, 2009 at 7:43 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
When I mentioned Seaside I was not thinking explicitly in terms of Top- Purpose...
What I like is that you have package but you have a kind of modules = object-oriented I would like to have
Collections-Kernel Collections-Kernel-Tests Collections-Arrayed Collections-Arrayed-Tests
Network-Kernel Network-Kernel-Tests ...
So that I can get all the packages with their tests if I want. Also when I browse the package I see the tests and the other points grouped togethe
(Purpose-)Rest
where
Purpose = Tests, Examples, .. Rest = Kernel, Collections, Network, ...
Note that this is the *package* structure (what you see in MC), not the class category structure. The latter could be more fine grained at the lower level (e.g., Tools-Debugger, Tools-Inspector, ... as it is structured now).
The consequence would be that we have packages like
Kernel Collections Tools ... Tests-Kernel Tests-Collections Tests-Tools
I'm not convinced that this is the right structure, though, as we end up with lots of Test-xyz packages.
As an alternative, I can imagine the package scheme
Top-Rest
where we have a very coarse grained Top level. For instance, we would have the following Top items:
Kernel Graphics Libraries Tools Tests
This means, we would have packages like
Kernel-Numbers Kernel-Traits Kernel-Compiler ... Libraries-Collections Libraries-Regex Libraries-Network ... Tests-Kernel Tests-Libraries ...
I'm curious if there are other ideas around. One way or the other, we need to clean this up. Right now it is a mess. E.g., there is a top level package MethodFinder, while all other tools are in the Tools package.
INdEeD
:)
Cheers, Adrian
stef
On Jan 31, 2009, at 10:51 AM, Stéphane Ducasse wrote:
I like the seaside organization
Top-(Purpose-)(Platform-)Rest
* Seaside-Canvas contains he canvas implementation. * Seaside-Squeak-Canvas contains the platform specific code of the canvas implementation. * Seaside-Examples-Canvas contains example code showing off the canvas implementation. * Seaside-Tests-Canvas contains the tests for the canvas implementation. * Seaside-Tests-Squeak-Canvas contains the platform specific tests of the canvas implementation.
On Jan 30, 2009, at 3:54 PM, Adrian Lienhard wrote:
On Jan 30, 2009, at 15:33 , Michael Rueger wrote:
Stéphane Ducasse wrote:
so what are the organizations we can use? Ideally I would like to have the test associated with their packages.
XXX XXXTests
The problem with that naming scheme is that then the tests would always be loaded together with their tests because of the simple string matching Monticello does. Which isn't something you want when doing application/runtime builds.
That's why I proposed the Plugin-* and Tests-* naming schemes.
+1
Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre Bergel wrote:
nonono ;-) See earlier mails in this thread, this way you end up with the tests stored in the core package because e.g. Collections-Kernel also matches Collections-Kernel-Tests.
Is it a bad thing?
<beReadyToShot> To that extend, I was wondering why we have the TestCase class. Ideally, I would like to have all the test methods coming along with the domain. As I have for documentation and comment. When I browse Lukas' code, the complete class hierarchy in the domain is duplicated in the tests. When we wrote the tests of the collection, we duplicated even method categories! With all that said, feel free to shot :-) </beReadyToShot >
For "normal" development work the test code "pollutes" the work environment IMHO. It also would make it harder to deploy applications where you want to strip out the test code (or not load it in the first place). Michael
On Feb 10, 2009, at 10:33 AM, Michael Rueger wrote:
nonono ;-) See earlier mails in this thread, this way you end up with the tests stored in the core package because e.g. Collections-Kernel also matches Collections-Kernel-Tests.
but if Collections-Kernel-Tests is a package then it will not be stored. Then why having tests close to the code is a problem I could do Collections-Kernel dropTests et voila! Stef
michael
On Tue, Feb 10, 2009 at 7:43 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
When I mentioned Seaside I was not thinking explicitly in terms of Top- Purpose...
What I like is that you have package but you have a kind of modules = object-oriented I would like to have
Collections-Kernel Collections-Kernel-Tests Collections-Arrayed Collections-Arrayed-Tests
Network-Kernel Network-Kernel-Tests ...
So that I can get all the packages with their tests if I want. Also when I browse the package I see the tests and the other points grouped togethe
(Purpose-)Rest
where
Purpose = Tests, Examples, .. Rest = Kernel, Collections, Network, ...
Note that this is the *package* structure (what you see in MC), not the class category structure. The latter could be more fine grained at the lower level (e.g., Tools-Debugger, Tools-Inspector, ... as it is structured now).
The consequence would be that we have packages like
Kernel Collections Tools ... Tests-Kernel Tests-Collections Tests-Tools
I'm not convinced that this is the right structure, though, as we end up with lots of Test-xyz packages.
As an alternative, I can imagine the package scheme
Top-Rest
where we have a very coarse grained Top level. For instance, we would have the following Top items:
Kernel Graphics Libraries Tools Tests
This means, we would have packages like
Kernel-Numbers Kernel-Traits Kernel-Compiler ... Libraries-Collections Libraries-Regex Libraries-Network ... Tests-Kernel Tests-Libraries ...
I'm curious if there are other ideas around. One way or the other, we need to clean this up. Right now it is a mess. E.g., there is a top level package MethodFinder, while all other tools are in the Tools package.
INdEeD
:)
Cheers, Adrian
stef
On Jan 31, 2009, at 10:51 AM, Stéphane Ducasse wrote:
I like the seaside organization
Top-(Purpose-)(Platform-)Rest
* Seaside-Canvas contains he canvas implementation. * Seaside-Squeak-Canvas contains the platform specific code of the canvas implementation. * Seaside-Examples-Canvas contains example code showing off the canvas implementation. * Seaside-Tests-Canvas contains the tests for the canvas implementation. * Seaside-Tests-Squeak-Canvas contains the platform specific tests of the canvas implementation.
On Jan 30, 2009, at 3:54 PM, Adrian Lienhard wrote:
On Jan 30, 2009, at 15:33 , Michael Rueger wrote:
Stéphane Ducasse wrote:
so what are the organizations we can use? Ideally I would like to have the test associated with their packages.
XXX XXXTests
The problem with that naming scheme is that then the tests would always be loaded together with their tests because of the simple string matching Monticello does. Which isn't something you want when doing application/runtime builds.
That's why I proposed the Plugin-* and Tests-* naming schemes.
+1
Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
On Feb 10, 2009, at 10:33 AM, Michael Rueger wrote:
nonono ;-) See earlier mails in this thread, this way you end up with the tests stored in the core package because e.g. Collections-Kernel also matches Collections-Kernel-Tests.
but if Collections-Kernel-Tests is a package then it will not be stored.
Its contents will be stored in Collections-Kernel because of the way Monticello defines package contents by name matching.
Then why having tests close to the code is a problem I could do
Collections-Kernel dropTests et voila!
It might be just my personal work style/habit, but if I'm "using" a package I don't want to have the tests in my work environment. Less stuff, less clutter, less distraction. Also searching for senders etc is made harder because of all the usages in test classes show up as well. Michael
On Feb 10, 2009, at 1:26 PM, Michael Rueger wrote:
Stéphane Ducasse wrote:
On Feb 10, 2009, at 10:33 AM, Michael Rueger wrote:
nonono ;-) See earlier mails in this thread, this way you end up with the tests stored in the core package because e.g. Collections-Kernel also matches Collections-Kernel-Tests.
but if Collections-Kernel-Tests is a package then it will not be stored.
Its contents will be stored in Collections-Kernel because of the way Monticello defines package contents by name matching.
Ah yes shit. I hate this pattern matching. Now can we have the same as in Seaside. I imgaine that they have several package with non matching names.
Top-(Purpose-)(Platform-)Rest
* Seaside-Canvas contains he canvas implementation. * Seaside-Squeak-Canvas contains the platform specific code of the canvas implementation. * Seaside-Examples-Canvas contains example code showing off the canvas implementation. * Seaside-Tests-Canvas contains the tests for the canvas implementation. * Seaside-Tests-Squeak-Canvas contains the platform specific tests of the canvas implementation.
Then why having tests close to the code is a problem I could do
Collections-Kernel dropTests et voila!
It might be just my personal work style/habit, but if I'm "using" a package I don't want to have the tests in my work environment. Less stuff, less clutter, less distraction. Also searching for senders etc is made harder because of all the usages in test classes show up as well.
but then you miss the point of tests been an active documentation. Then we could really have dropTest process. Else the real pain is that we will have to synchronise tests and package and there is nothing less useful than to have tests that are not in sync with a package
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Feb 10, 2009, at 13:26 , Michael Rueger wrote:
Stéphane Ducasse wrote:
On Feb 10, 2009, at 10:33 AM, Michael Rueger wrote:
nonono ;-) See earlier mails in this thread, this way you end up with the tests stored in the core package because e.g. Collections-Kernel also matches Collections-Kernel-Tests.
but if Collections-Kernel-Tests is a package then it will not be stored.
Its contents will be stored in Collections-Kernel because of the way Monticello defines package contents by name matching.
Then why having tests close to the code is a problem I could do
Collections-Kernel dropTests et voila!
It might be just my personal work style/habit, but if I'm "using" a package I don't want to have the tests in my work environment. Less stuff, less clutter, less distraction. Also searching for senders etc is made harder because of all the usages in test classes show up as well.
I feel the same about it. Also I don't particularly like the solution with the space, and/or camel case labels (like "Collections- KernelDropTests"). Michael, what would you suggest as a scheme? How about the following solution I suggested in a previous mail? Kernel-Numbers Kernel-Traits Kernel-Compiler ... Libraries-Collections Libraries-Regex Libraries-Network ... Tests-Kernel Tests-Libraries ... In the class categories we could still have a fine-grained structure for tests, like Tests-Kernel-Numbers Tests-Kernel-Traits Tests-Libraries-Collections ... Like this we have sort of a "tests close to the code" since the last part, e.g., "Libraries-Collections" would match the category structure of the implementation. Basically it's just that we prefix the categories with "Test-" and that we have a coarse Top level structure. Stef, wouldn't that also (partly) satisfy your wish of organizing tests close to the code? Adrian
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian Lienhard wrote:
KernelDropTests"). Michael, what would you suggest as a scheme? How about the following solution I suggested in a previous mail?
IIRC that was exactly what I suggested as well :-) So I'm all for it :-) Michael
Kernel-Numbers Kernel-Traits Kernel-Compiler ... Libraries-Collections Libraries-Regex Libraries-Network ... Tests-Kernel Tests-Libraries ...
In the class categories we could still have a fine-grained structure for tests, like
Tests-Kernel-Numbers Tests-Kernel-Traits Tests-Libraries-Collections ...
Like this we have sort of a "tests close to the code" since the last part, e.g., "Libraries-Collections" would match the category structure of the implementation. Basically it's just that we prefix the categories with "Test-" and that we have a coarse Top level structure. Stef, wouldn't that also (partly) satisfy your wish of organizing tests close to the code?
Adrian
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I feel the same about it. Also I don't particularly like the solution with the space, and/or camel case labels (like "Collections- KernelDropTests"). Michael, what would you suggest as a scheme? How about the following solution I suggested in a previous mail?
Kernel-Numbers Kernel-Traits Kernel-Compiler ... Libraries-Collections Libraries-Regex Libraries-Network ... Tests-Kernel Tests-Libraries ...
In the class categories we could still have a fine-grained structure for tests, like
Tests-Kernel-Numbers Tests-Kernel-Traits Tests-Libraries-Collections ...
Like this we have sort of a "tests close to the code" since the last part, e.g., "Libraries-Collections" would match the category structure of the implementation. Basically it's just that we prefix the categories with "Test-" and that we have a coarse Top level structure. Stef, wouldn't that also (partly) satisfy your wish of organizing tests close to the code?
I do not like it but it looks like the best compromise with the tools we have right now For me it goes against OOP and encapsulation but....there is a pattern matching ugly trick. Stef
participants (7)
-
Adrian Lienhard -
Alexandre Bergel -
bryce＠kampjes.demon.co.uk -
David T. Lewis -
Lukas Renggli -
Michael Rueger -
Stéphane Ducasse