Hmm, if the default action is to proceed, this would be completely
compatible with the way things work today, while allowing new UIs to
customize the response (ask the user, roll back, do it anyway, check a
preference...)

Daniel

"John W. Sarkela" <sarkela at sbcglobal.net> wrote:
> 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
> >>>
> >