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
> <[email protected]> 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
>>>>>> [email protected]
>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [email protected]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
>>>>> project
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [email protected]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [email protected]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
