>
> Good thing to have a rationale for where you want to be going and why...
> It would be interesting to have it documented.For example:
> - A package is holding strong references to class/methods belonging to
> it or not?
did you read the class comment of RPackage?
Because this is explained normally.
Now the answer
a RPackage does not hold references to class or compiledMethod but to
class names and selectors
so that it could potentially be used for now working classes.
> - Does a class know (directly point to) its package, or is it a
> service provided by some helper object?
RPackageOrganizer
so far we did not modify class but manage the invariant class/package using
announcement
> - Does a method know (directly point to) its package, or is it a
> service provided by some helper object?
CompiledMethod package
and this is manager by PackageOrganizer
> - Are there unpackaged classes/methods (pointing to nil?), is there a
> service to discover them?
Not that I know.
> - What is the relation with st80 classification (class categories and
> method protocols)? Is it completely orthogonal?
Totally.
> - Should class/methods have multi-classification (belong to several
> categories protocols)?
A class belongs to only one packages
Now you can have tags (I implemented it but may be we will not use it)
to have virtual categories
For methods packages are orthogonal to categories (now we are
maintaining for the moment the * notation).
> You can call that tags if you want...
> pro/cons for each point
>
> Then it's another thing to tell how you will reach these goals, and
> if/how you will maintain compatibility with MC (a vital tool) or other
> tools (browsers nautilus RB change list/change sorter etc...) - which
> might be possible by faking categories/protocols.
the compatibility is first
when you load
-> * star notation in the mcz -> category announcement ->
extension in the repackage
saving
-> we should check that the package and the categories get the
same contents -> saving with * in category
So for now we will maintain a compatibility and in the future we will see.
> For french: Je dirai qu'on a l'eau à la bouche, mais qu'on reste un
> peu sur notre faim ;)
>
>>> So, we rolled back...
>>>
>>> Attempt 2) Let each Class Category be one RPackage.
>>>
>>> Ok, this is very simple (and that's the beauty on it)... each tools and
>>> conventions will match perfectly. Only problem here is that now, Monticello
>>> is not compatible anymore. So, we worked on the concept of RPackageSet, to
>>> replace PackageInfo use into Monticelo packages (we need them to load/save
>>> packages and stay compatible). RPackageSet is exactly what its name says: a
>>> set of RPackage instances (created on the fly, by pattern matching, so, is
>>> still some kind of a hack), that is polymorphic with PackageInfo in the
>>> monticello context. Thus, everything in the system can remain unchanged (or
>>> almost no change, the refactoring engine needs some adjusts).
>>> One extra bonus with this approach is that it let us think on more cool
>>> refactors in the future: we can for instance replace class categories (now a
>>> symbol) with an RPackage... and continue simplifying the system in several
>>> ways.
>>>
>>> ...and that's where we are now.
>>> We are working hard on stabilizing the system, but that will take still
>>> some days more... after that, we will be really close to the PackageInfo
>>> removal.
>>>
>
> Good, if the system was too complex in order to analyze all
> implications and completely planify the change path, then trial and
> error might be a solution, it's not a shame, but you have to write
> your goals to better remind them, and maybe make some amendments to
> your rationale because of some unanticipated features (and providing
> some degree of compatibility can lead to additional features).
Compatibitilty of MC and configurations will be maintain.
If we could have got rid of the last one it would have solved a lot of our pain.
>
>>> PLEASE: PackageInfo users, take this into account: PackageInfo will pass
>>> away... and is one of the parts of the system that cannot be deprecated,
>>> they has to be completely removed, prepare your tools for the rise of
>>> RPackage :)
>>>
>>> Cheers,
>>> Esteban
>>>
>
> Such a change will require a stable and if possible well documented
> API (which should be quite straightforward once you have rationalized
> your design).
Have a look at the RPackage class. It is really nice.
The pain is not it, the pain is the system and the pattern matching and event
and ….
and having packages and categories.
Stef
>
> Nicolas
>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
