Exactly the point. Perhaps DVS could in the future signal a
Notification upon redefinition. That way redefinitions could
be easily loaded (with notifications of redefinitions that are
typically ignored) but that allows a more careful loader policy
to intercept the notification, preferably prior to changing the
state of the image.

I suppose my point is that the flavor of Exception that should
drive the policy is more like a Notification than an Error.

John

On Monday, March 31, 2003, at 09:52 AM, Daniel Vainsencher wrote:

> DVS is also capable of handling class extensions.
>
> It doesn't raise an exception on overriding/changing stuff, which would
> be a a good addition, making it easier to have policies about that.
>
> What do I mean policy? a package should almost never override anything.
> Having code in your package that overrides code in your prerequisites
> can cause unexpected behavior for users that want to use/modify stuff
> other than your package (meaning - everybody but yourself ;-).
>
> Daniel
>
> "John W. Sarkela" <sarkela at sbcglobal.net> wrote:
>> The deeper issue is that Class structure is typically an organization
>> scheme that is orthogonal to a functional/utilitarian scheme.
>>
>>  From a usage/loading point of view, one wishes to manage source
>> code based on the function points that it introduces into the system,
>> rather than *all* of the class structure of *all* of the affected
>> classes.
>>
>> For example, a well defined framework will commonly extend
>> the behavior of base classes like Object or Collection.
>> Thus, for the purposes of managing functional chunks of
>> code, one almost certainly needs to store and access code
>> based upon a functional capability point of view, rather than
>> a runtime hierarchical structure point of view.
>>
>> It was for these reasons that SWT used build scripts to load
>> functional elements of the image and used the ginsu module
>> mechanism to handle modules that could contain "loose methods"
>> that extended the behavior of existing classes. It further
>> ensured that each definitional element of code was uniquely
>> defined in the image. This is required to avoid problems of
>> one module "stepping on" definitions from previously loaded
>> modules.
>>
>> Cheers,
>>
>> :-}> John Sarkela
>>
>> On Monday, March 31, 2003, at 07:26 AM, jennyw wrote:
>>
>>> On Mon, Mar 31, 2003 at 09:30:49AM +0100, goran.hultgren at bluefish.se
>>> wrote:
>>>> Yep. Well, Squeak doesn't "play" that well with filebased source
>>>> management tools.
>>>> In Squeak we now have DVS which essentially is a "smart"
>>>> file-in/file-out mechanism which makes it at least practical to use
>>>> CVS
>>>> or any other filebased source management tool - but it is still not 
>>>> a
>>>> perfect fit and will probably never be.
>>>
>>> This isn't so much a suggestion as a potentially dumb question, but 
>>> ...
>>>
>>> If there was an option to filed-out in a directory structure instead 
>>> of
>>> a single file, such as:
>>>
>>> category/classname/classdef
>>> category/classname/methodcategory/method1
>>> category/classname/methodcategory/method2
>>> etc.
>>>
>>> And filed-in in the same manner, wouldn't source control systems be
>>> able
>>> to handle that better?  I know this probably wouldn't work well in 
>>> CVS
>>> (since it doesn't support renames), but with Subversion (successor to
>>> CVS), BitKeeper, or a number of more recent CMS systems, it might 
>>> work
>>> better.  Or not?
>>>
>>> Jen
>>>
>