MonticelloPackageBrowser

Alexandre Bergel bergel at iam.unibe.ch
Sun May 22 21:57:22 UTC 2005


Hello Andreas,

Thanks for having had a look at the package browser.

> Some comments. First off, it would be useful if the web site could say 
> more about the motivation behind your approach. 

I do not like the website neither. Just matter of time...

> The description of the 
> current situation seems like nit-picking to me - it would be fairly 
> straightforward to add support for PI conventions to the browsers, or 
> making moving methods or renaming packages one-click exercises 

The idea beneath was to step back a bit and to see where and how PackageInfo can be improved. Clearly string manipulations should be avoided. One reason that I didn't notice at the beginning is for efficiency. 

For instance, try to add the package 'System', and then browse it. Prior to this, a snapshot is performed. Here is the time taken:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
PackageInfo named: 'System'
Time millisecondsToRun: [(MCPackage named: 'System') snapshot]
=> 49886 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

With the new design of packages you just have to click on System to see instantaneously the result...


> But clearly, this is not 
> enough to motivate a new package system so some information on why you 
> feel this is necessary would be nice.

As Stef said, I was a bit fuzzy actually. I __do not__ propose a new package model, but just a better implementation of the existing one. Rather than manipulating strings, a package consists of refences to classes and method references.

The class PackageInfo and Package have the a similar interface.

> * Which packages have modified this class? 

This is something I want to tackle. VW does it in a very nice way (hierarchy/package button).



> * Is method #foo an extension method? This is critical to know because 
> one might accidentally use a pet method of some other package (say, 
> Collection>>gather: which is defined by package info) that will not be 
> present in the long term.

There are many improvements I want to add, your point is one of these. Representing extended method is crucial.

Cheers,
Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



More information about the Squeak-dev mailing list