Le 9 mars 04, à 18:48, Colin Putney a écrit :

>
> On Mar 9, 2004, at 9:33 AM, Romain Robbes wrote:
>
>> I would have asked you anyways ...
>> I'd like to try out stuff with it, it might be a good brower
>> for BrowseUnit.
>
> If I can be of any help, please let me know.

don't worry for that ...
another interesting stuff to do would be doing inspectors
with your package, possibly like the inspector in visualworks 7.2,
which can also browse the methods of the inspected object.

>
>> Yes it is ... it might still be useful to browse a few packages at 
>> the time, though.
>
> I'm not sure I understand. Are you thinking of a "merged" view where 
> several packages are combined into a single namespace (for lack of a 
> better term) and the browser operate on that? Or a version of the 
> Package Browser that only shows some of the packages in the system?

Just the latter ... actually you seem to only have the choice between 
all
packages and one package.

>
>> Another "feature request" would be that your PackageBrowser does
>> not allow yet to directly browse class extensions, as the Monticello 
>> Browser does
>> (but you can't modify stuff in the latter). But it seems that the 
>> "chase implementors"
>> facility finds the extensions .
>
> Yes, mutability is the tricky part. What would it mean to create a 
> class in the '*Extensions' virtual category? I don't think PackageInfo 
> can handle that case at the moment.

hmmm ... can't you just disallow it for a start ?  (using a notion of 
immutable nodes?)

>  I'll see what I can do for the next release, but I think probably the 
> proper way to address this is with a proper Package class. Now that we 
> have robust SystemChangeNotifications and a UI for manipulating 
> packages, it's more feasible than it was.
>
>>>> And it seems to be extensively tested :-).
>>>
>>> My to do list has some tests that are still missing, but I think the 
>>> coverage is generally pretty good.
>>
>> Definitely yes. While browsing your code and your test code, I 
>> actually learned quite
>> a lot. I think that your mock classes could be released separately as 
>> they seem
>> quite nice to use on their own.
>
> Yes. I think I'll have to split OB up in to several packages in the 
> near future, so as not to have too many dependencies. I'd like to add 
> support for the RB, of course, and perhaps for StarBrowser 
> classifications as Stéphane suggested, but the main browsers shouldn't 
> depend on those packages.
>

By the way I saw that your browser can have a collection of text panes, 
not only one.
How hard would it be to have a browser with several selections, like 
whisker ?
(I naively tried to duplicate the sole panel in the collection, but I 
didn't ended
with two panel when reopening the browser)

Concerning the RB, there is work to do to make the refactorings easily 
accessible
to everyone as services. A while ago I looked a bit into that, but 
didn't get very far due
to lack of time (as always ...). I have to look further in your Action 
and Actor code,
to see if they could be integrated there (IIRC this is the way you 
implements menu
actions, right ?)


> The mocks and perhaps some of the abstract classes for testing the 
> browsers could also be factored out into separate packages.
>

That could be useful to other people, I think.

> -cwp
>
>
>