Miscelaneal Experiments and Observations

[I thought, after OE screwed up the threading last time (sorry about that),
that I'd use a slightly more imaginative title  -- it's a heading from a
1703 book of art/craft techniques]

---------------

Very, very, small nit and a not-much-bigger request about the
#methodAdded:toPackage: event.  The nit is that I think the name is
misleading since it isn't triggered when a (pre-existing) method is added to
a package; I suggest #methodAdded:inPackage:.  The request is that when you
change the names of system events, I'd appreciate it if you mention it
somewhere.  The problem is that listening for an event with the wrong name
doesn't cause any kind of runtime/compile-time error, but tools just
silently stop working properly.

---------------

Not a bug, an observation.  I really like the new Visual Object Finder on
the toolbar -- very slick.

---------------

The new class creation dialog is nice (I'm using the non-RB version).  It
could be slightly improved if it came up with the class name already
selected, since that is going to be changed for sure.  Also I think that the
className and isPackaged subviews should have their #isTabStop aspects set
to true and the StaticRectangle used for the separator line should have its
#isTabStop turned off.

---------------

Bug #809 (Package properties not set properly from the PAI) also seems to
affect the VC.  At least, I can't successfully edit sub-menus from the VC's
embedded PAI anymore.  They appear to edit OK, but then the changes are not
written back to the view.

Something of a nuisance ;-)

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> [I thought, after OE screwed up the threading last time (sorry about
that),
> that I'd use a slightly more imaginative title  -- it's a heading from a
> 1703 book of art/craft techniques]
>
> ---------------
>
> Very, very, small nit and a not-much-bigger request about the
> #methodAdded:toPackage: event.  The nit is that I think the name is
> misleading since it isn't triggered when a (pre-existing) method is added
to
> a package; I suggest #methodAdded:inPackage:.

I'm not sure that either is right, since the package argument is really a
'suggestion', and could be nil if the new method is not loose, or could be
overridden if a 'default package' is set. Also at the time the event is
triggered the method may yet have been packaged (if it is loose), since the
PackageManager observes the event in order to arrange the initial packaging.
#methodAdded:forPackage: might be best?

>...The request is that when you
> change the names of system events, I'd appreciate it if you mention it
> somewhere.  The problem is that listening for an event with the wrong name
> doesn't cause any kind of runtime/compile-time error, but tools just
> silently stop working properly.

I was quite reluctant to change it in a non-compatible way, but there was
little choice because we wanted to be able to support the packaging of new
loose methods properly (for rename refactorings, drag&drop, edit & save,
adding all new program objects to a default package, that sort of thing),
and after some thought it was obvious that not only would the existing
single #methodAdded: event not cut it, since one could not distinguish
actual additions from modifications, but that it would be necessary to
include the 'suggested' target package as an argument so that the package
manager could correctly package the method without change flags being upset
by having to 'repackage' the method after addition.

This is, in fact, #720 which you can find in the various HTML reports - the
fix note associated with this will be promoted into a release note when the
final release notes are published. I would agree that it is not at all easy
to locate, but there are hundreds of changes many of which could potentially
cause compatibility issues, and many different ways of filtering or
organising them according to peoples' interests. We'd like to have a better
way to draw people's attention to specific issues

> Not a bug, an observation.  I really like the new Visual Object Finder on
> the toolbar -- very slick.
>
> ---------------
>
> The new class creation dialog is nice (I'm using the non-RB version).  It
> could be slightly improved if it came up with the class name already
> selected, since that is going to be changed for sure.  Also I think that
the
> className and isPackaged subviews should have their #isTabStop aspects set
> to true and the StaticRectangle used for the separator line should have
its
> #isTabStop turned off.

Thanks, #821.

> ---------------
>
> Bug #809 (Package properties not set properly from the PAI) also seems to
> affect the VC.  At least, I can't successfully edit sub-menus from the
VC's
> embedded PAI anymore.  They appear to edit OK, but then the changes are
not
> written back to the view.
>
> Something of a nuisance ;-)

Yes (#822), especially since the cause of #809 is fairly obvious (the image
stripper of a Package is held indirectly as its binary store bytes, and so
the aspect has to be immutable so that when changed it is written back to
the package in its entirety, and therefore #809 is easily corrected by the
addition of a #beImmutable at the correct point in Package
class>>publishedAspectsOfInstances. Of course the Menus may be a similar
issue.

Regards

Blair

Blair

> > a package; I suggest #methodAdded:inPackage:.
>
> I'm not sure that either is right, since the package argument is really a
> 'suggestion', and could be nil if the new method is not loose, or could be
> overridden if a 'default package' is set. Also at the time the event is
> triggered the method may yet have been packaged (if it is loose), since
the
> PackageManager observes the event in order to arrange the initial
packaging.
> #methodAdded:forPackage: might be best?

That'd be fine by me.

> >...The request is that when you
> > change the names of system events, I'd appreciate it if you mention it
> > somewhere.  The problem is that listening for an event with the wrong
name
There's no question that it's an improvement.   (BTW, it'd be nice if the
#methodUpdated: notification gave the old CompiledMethod object as well as
the new one -- it's certainly not *necessary*, nor even urgent, but if that
happened someday then I I'd be able to ditch a part of a database of every
CompiledMethod in the system).

I may as well mention: I strongly support your policy of improving the
system where necessary, even at the occasional expense of total backward
compatibility.  That's the only way to keep the code "fresh".

> This is, in fact, #720 which you can find in the various HTML
> reports - the fix note associated with this will be promoted into
> a release note when the final release notes are published.

I can't find it on any of my extracts from the bug-list.  Where I can see
#720 there's no fix note in the extract.  It doesn't matter much, though, as
long as it's somewhere in the eventual release note.  That's perfectly
adequate (of course, I don't get to see the release note until later, but
that's my fault for taking part in the beta... ;-)

What I *am* going to do is add a bunch of assertions about the
#publishedEvents of various system objects to my installation/configuration
scripts.  It's something I should have thought of before, but it's only just
occurred to me as I'm writing.  Doh...  (Or possibly the post-installation
scripts of the relevant packages.  Hey ho, isn't hind-sight wonderful?)

> there are hundreds of changes many of which could
> potentially cause compatibility issues, and many different ways of
> filtering or organising them according to peoples' interests. [...]
> We'd like to have a better
> way to draw people's attention to specific issues

I think it'd be a valuable service if you could make a dynamically
generated, .CSV extract from (selected bits of) your change database
available online.  It's not a thing to undertake lightly (even if it were
technically trivial, and I bet it's not), e.g. I know you don't like making
public statements about forthcoming changes, so they shouldn't appear in the
list, but newly added bug-reports should.  But something for the future
perhaps ?  (Perhaps, too, you could limit it so that only purchasers of the
Pro edition could see more than the basic bug-list.)

A related idea, how easy would it be (may not be possible at all) to add an
"Incompatible API change" flag to the change list ?

> Blair

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...

[re: method event change]

> There's no question that it's an improvement.   (BTW, it'd be nice if the
> #methodUpdated: notification gave the old CompiledMethod object as well as
> the new one -- it's certainly not *necessary*, nor even urgent, but if
that
> happened someday then I I'd be able to ditch a part of a database of every
> CompiledMethod in the system).
>
> I may as well mention: I strongly support your policy of improving the
> system where necessary, even at the occasional expense of total backward
> compatibility.  That's the only way to keep the code "fresh".

Ahem, then I hope you won't mind too much that I've decided to change it
again. The event has reverted to #methodAdded:, but the argument is now the
<CompilationResult> that contains the method, package, etc. This change will
allow more flexibility over the packaging decision without requiring further
parameters, and allows for future extension without having to change the
event yet again. In addition #methodUpdated: is now passed a
<CompilationResult> (instead of the new compiled method) that contains both
new and old methods, which should meet your requirement (and also, BTW,
simplifies a number of the system tools such as MethodBrowser a little).

> ...
> I think it'd be a valuable service if you could make a dynamically
> generated, .CSV extract from (selected bits of) your change database
> available online.  It's not a thing to undertake lightly (even if it were
> technically trivial, and I bet it's not), e.g. I know you don't like
making
> public statements about forthcoming changes, so they shouldn't appear in
the
> list, but newly added bug-reports should.  But something for the future
> perhaps ?  (Perhaps, too, you could limit it so that only purchasers of
the
> Pro edition could see more than the basic bug-list.)
>

Probably the only real solution is to have some way for customers to search
the bugs database. Something for the future.

> A related idea, how easy would it be (may not be possible at all) to add
an
> "Incompatible API change" flag to the change list ?

It might be. I need to go through the D5 bugs/enhancements list at some
point soon, and if possible I will put that in.

Regards

Blair

Blair,

> Ahem, then I hope you won't mind too much that I've decided to change it
> again.

<g>

Sounds good to me.

> Blair

    -- chris