PB/Default package

In the Package Browser/Resources pane. If there is no selection, double
clicking in the pane results in a "No object selected" walkback.

In the Package Browser/Globals pane. If there is no selection, the context
menu "References" command is still enabled and results in a "UndefinedObject
does not understand #key" walkback.

If there is a default package, refactoring methods makes them loose methods
in the default package. As an example, set a default package and then do a
method rename.

After further investigation, the default package seems very keen to claim
ownership of methods. Any method added to a class will be placed in the
default package as a loose method. (This could be a useful feature, but I
assumed that being named "default" meant that only source objects that would
have gone into "Undeclared" go into it. A "capture" package?)

(Assuming the above is a feature) If a method is added to a class, (which
becomes a loose method in the default package) the Package Browser/Loose
methods pane is not updated, and you need to switch packages before it is
listed.

Thanks,
Steve Waring

"Steve Waring" <[hidden email]> wrote in message
news:[hidden email]...
> In the Package Browser/Resources pane. If there is no selection, double
> clicking in the pane results in a "No object selected" walkback.
>
> In the Package Browser/Globals pane. If there is no selection, the context
> menu "References" command is still enabled and results in a
"UndefinedObject
> does not understand #key" walkback.


Thanks, #826 and #827.

>
> If there is a default package, refactoring methods makes them loose
methods
> in the default package. As an example, set a default package and then do a
> method rename.
>
> After further investigation, the default package seems very keen to claim
> ownership of methods. Any method added to a class will be placed in the
> default package as a loose method. (This could be a useful feature, but I
> assumed that being named "default" meant that only source objects that
would
> have gone into "Undeclared" go into it. A "capture" package?)

This is indeed by design. The role of the "default package" is now that of
the default home for all code objects one adds to the system, including
those defined by file-ins, whatever. This includes new (but not modified)
methods. New classes added a result of evaluating a class creation mechanism
will also go into the default package, but one can explicitly choose the
package of classes added through the Create Subclass dialog. I believe this
is the behaviour asked for by Joseph Pelrine, and I am sure he will correct
me if not.

The new behaviour of the default package makes it somewhat more intrusive
that it used to be, and as such it is establishes a mode that one is more
likely to want to leave "off" than before. On the other hand it is much more
useful when one is filing in code, or extending existing classes.

Unfortunately the default package will snaffle the results of method
renaming refactorings, because these boil down to the addition of a new
method, and the removal of the old. I think this is an undesirable side
effect, and needs addressing (#828). In the meantime I suggest turning off
the default package while refactoring.

BTW: The fact that the default package is settable from the Class Browser's
Class menu is simply because that is where the command has been
historically. It made sense in the past, because there was no way to
explicitly package new classes (which can now be done directly from the
Create Subclass dialog). Actually one might argue that the 'Default Package'
is mostly intended to handle those objects which would end up defaulting to
their owning class' package, rather than to those end up in 'Uncommitted' by
default, e.g. new methods rather than new classes. Anyway we were intending
on changing the UI to fit, which should make things clearer.

> (Assuming the above is a feature) If a method is added to a class, (which
> becomes a loose method in the default package) the Package Browser/Loose
> methods pane is not updated, and you need to switch packages before it is
> listed.

#829.

Regards

Blair

Hi Blair,

> This is indeed by design. The role of the "default package" is now that of
> the default home for all code objects one adds to the system, including
> those defined by file-ins, whatever. This includes new (but not modified)
> methods. New classes added a result of evaluating a class creation
mechanism
> will also go into the default package, but one can explicitly choose the
> package of classes added through the Create Subclass dialog. I believe
this
> is the behaviour asked for by Joseph Pelrine, and I am sure he will
correct
> me if not.

Thanks, this sounds useful. Is there a reason that modified methods are not
included? It is getting close to the role of the change.log, but it would be
handy to identify methods that are filed-in that replace existing methods.

Thanks,
Steve

"Steve Waring" <[hidden email]> wrote in message
news:[hidden email]...
> Hi Blair,
>
> > This is indeed by design. The role of the "default package" is now that
of
> > the default home for all code objects one adds to the system, including
> > those defined by file-ins, whatever. This includes new (but not
modified)
> > methods. ...
>
> Thanks, this sounds useful. Is there a reason that modified methods are
not
> included? It is getting close to the role of the change.log, but it would
be
> handy to identify methods that are filed-in that replace existing methods.

Handling of modified methods is a bit more controversial. In the case of a
file-in it would indeed seem sensible to store these in the default package
too, but where the modification occurs from a browser the question is more
open. Do you want all the methods you modify to end up in the default
package? Probably not.

Although the default package idea is undoubtedly useful, it has a worrying
"mode" like tendencies in that it is implicitly doing something that one
might not necessarily want, or realise/remember is going to occur. There is,
therefore, a balance to be struck, and that may not be quite right yet. Any
suggestions or better ideas would be welcome, although it is too late now
for anything other than relatively minor changes.

Regards

Blair