Method drag - packaging

Blair,

There's been a fair amount of discussion re packaging methods, and I'll
admit that I don't recall the current plans for the release.  FWIW, I'd be
happier if dropping a method on another class simply used the package of the
drop target (leave the method "unpackaged").  I do a lot of copying that
way, and will end up with a large number of incorrectly packaged methods.
It looks easy enough to fix by chosing the package command and unchecking
the box.  Also, the RB will make some of it unnecessary, and I'm  also
progressing toward having my code generator doing a lot of the work that I
do now by drag/drop/fix errors, at which point it won't matter much to me
either way.

Have a good one,

Bill

---
Wilhelm K. Schwab, Ph.D.
[hidden email]

Blair,

> FWIW, I'd be
> happier if dropping a method on another class simply used the package of
the
> drop target (leave the method "unpackaged").  I do a lot of copying that
> way, and will end up with a large number of incorrectly packaged methods.

As a follow up, it has already caused "trouble".  Actually, it was a nice
test of the runtime error logging, etc., but, ultimately an app that I
cranked out in a hurry (nice job integrating the RB!) didn't run as an exe
because #defaultModel was packaged with some other app and was stripped as a
result.

Perhaps more important, I suspect that newbies (and the rest of us) will
encounter problems with cyclic prerequisites because of unexpected
packaging.

Have a good one,

Bill

---
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> Blair,
>
> There's been a fair amount of discussion re packaging methods, and I'll
> admit that I don't recall the current plans for the release.  FWIW, I'd be
> happier if dropping a method on another class simply used the package of
the
> drop target (leave the method "unpackaged").  I do a lot of copying that
> way, and will end up with a large number of incorrectly packaged methods.
> It looks easy enough to fix by chosing the package command and unchecking
> the box.  Also, the RB will make some of it unnecessary, and I'm  also
> progressing toward having my code generator doing a lot of the work that I
> do now by drag/drop/fix errors, at which point it won't matter much to me
> either way.

The way it is supposed to work (and the way it will work in the eventual
release0 is that the package of the dropped method should be the source
package if the source was loose, or the target package if it was not. On
balance this seems to be the most sensible option, though inevitably there
will be times when it is not what one might want. It is different to D4
though, so it is something that might take some getting used to.

Regards

Blair

Blair,

> The way it is supposed to work (and the way it will work in the eventual
> release0 is that the package of the dropped method should be the source
> package if the source was loose, or the target package if it was not.

Got it.  That makes sense.

> On
> balance this seems to be the most sensible option, though inevitably there
> will be times when it is not what one might want. It is different to D4
> though, so it is something that might take some getting used to.

Not nearly as much as the current behavior of beta 3 :)  I'll have to use it
some to be sure, but, I think it will work out nicely.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]