Bill

your english is too rich for us poor non native speakers so we may miss what 
you imply :)


> Stef,
> 
> I am doing some housekeeping toward building a new image.  Changes such as 
> below have allowed me to get Migrate into an almost-releasable state.  One of 
> its jobs is to look for code that is at risk of being lost, and that feature 
> is detecting a LOT of code that should be safe; it is probably due to the 
> extra packages.  I had hoped that I could safely avoid the "double save" 
> problem, but this is even worse than that :(

what happen?

> Absent a simple solution, the answer is to delete DolphinCompatibility and 
> others.  The next question is then: will I have problems with dependencies 
> between the sub-packages?  

which subpackages?

> I am wondering whether there could be problems saving separate packages like
> 
>   DolphinCompatibility-Streams
>   DolphinCompatibility-ODBC
> 
> when DolphinCompatibility would be perfectly happy.
> 
> Does that make sense?
> 
> Bill
> 
> 
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Stéphane 
> Ducasse
> Sent: Wednesday, January 13, 2010 2:40 AM
> To: [email protected]
> Subject: Re: [Pharo-project] MC case sensitity and sub-packages
> 
> 
> On Jan 13, 2010, at 1:39 AM, Schwab,Wilhelm K wrote:
> 
>> Brian and others have told me that I could expect to define packages 
>> such as
>> 
>> DolphinCompatibility-ODBC
>> DolphinCompatibility-Streams
>> 
>> and save them all using DolphinCompatibility, or save just one specific part 
>> by giving the full name, such as DolphinCompatibility-ODBC.  I was unable to 
>> make it work reliably, and I think I might have just figured out why.
> 
> I really encourage you to save them as separate packages if you want to load 
> and save them all build a metacelloConfig (not difficult and worth).
> don;t define a package DolphinCompatibility in addition (else you will get in 
> trouble because your classes will be saved somehow twice)., I hate this 
> pattern matching behavior.
> 
>> Assertion: package names and class names must agree up to case; method 
>> categories (*packageName-etc) appear to be more forgiving.
>> 
>> It further appears that once one messes up by naming a category and package 
>> Dolphincompatibility instead of DolphinCompatibility, the only way to fix it 
>> is to delete the working copy of the package and re-create it with the 
>> correct case after renaming the category, or something like that.
> 
> probably I do not like that part of the system
>> 
>> Does that sound right?  Am I missing something that might cost me later?
>> 
>> Bill
>> 
>> 
>> _______________________________________________
>> 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

Reply via email to