Alex
I imagine that this is to avoid mistake like
Moose
Moose-X
Moose-Y
and that people do it
Moose-All
Moose-X
Moose-Y
If this is what you have in mind how would it work from a process
point of view
1- I create
Moose
2- I create
Moose-XXX
- wanring
3- remove/rename
Moose - Moose-All
The problem is that you cannot forbid that now.
Or do you? what is the impact of forbidden that now on existing code?
Stef
On Oct 12, 2008, at 11:19 AM, Alexandre Bergel wrote:
Let me put it in another way.
Is there a situation where a package named MyPackage should require
another package
In Visualworks there is no dash convention, which is much better...
This might be interesting in the context of discussion:
We documented the package naming conventions for Seaside 2.9 here:
http://code.google.com/p/seaside/wiki/PackageNaming
The complete list of packages is documented
Let me put it in another way.
Is there a situation where a package named MyPackage should require
another package MyPackage-Foo.
As we experienced, this evil dependency brings inconsistencies when
saving MyPackage.
What would it a nice way to prevent such situation ?
I imagine that this
It makes sense. But in that setting, creating a package named
'Seaside' and beginning to add some Seaside-... packages as required
would be disastrous. No? But maybe I am missing something here...
Cheers,
Alexandre
On 12 Oct 2008, at 11:46, Lukas Renggli wrote:
In Visualworks there is no
Stéphane Ducasse wrote:
I lukas I see that you group together all the tests and I would prefer
to have test associate with the package they test.
stef
Traditional PackageInfo users are expected to use the standard
implementation or roll their own, for each package that needs a custom
MC1.5+ Comes with a version of PackageInfo that has the notion of
package types. Predefined package types that you can make use of through
a simple dot suffix package name.
Dot suffixes are traditionally used for branches. We use them
extensively in Seaside.
Lukas
--
Lukas Renggli
Keith
the problems with such approaches is that each of these nice little
extensions will break the
analysis tools we are developing. I would prefer a good and stable
solution
over everybody can hack its own.
I want some invariants on top of which we can build other tools.
Stef
On Oct 12,
Maybe, one easy step to make MC simpler, is to remove (sub)categories
in packages. In that case, two packages, 'Moose' and 'Moose-Test' will
be completely unrelated.
Cheers,
Alexandre
On 12 Oct 2008, at 22:20, Stéphane Ducasse wrote:
Keith
the problems with such approaches is that each
Stéphane Ducasse wrote:
Keith
the problems with such approaches is that each of these nice little
extensions will break the
analysis tools we are developing. I would prefer a good and stable
solution
over everybody can hack its own.
I want some invariants on top of which we can build other
Dot suffixes are traditionally used for branches. We use them
extensively in Seaside.
I dont think you do, are you telling me that he package Seaside2.8a1
has a branch called .8a1
Yes, that's the 2.8 branch. Up to 2.8 every version had its own branch.
There are smaller examples in the
11 matches
Mail list logo
