AbstractFileClassLoader does not support getPackage

On Wed, Feb 1, 2012 at 4:00 AM, Eugene Burmako wrote:
> Subj. always returns null, even on valid package names (e.g. when I try to
> load one of the $lineXXX packages defined by REPL). Shall I submit a bug?

I don't think anyone ever wanted this before. I still don't know what
you'd want it for, but I implemented it for you in b2a21c4eac on the
theory that there's some interesting reason.

Ouch, I also implemented this stuff in https://github.com/scalamacros/kepler/commit/7d6637c024ec2d6d4a47ec2a684783f5943f0c22#diff-1. The changeset also sheds some light on potential applicability areas.

On 1 February 2012 19:29, Paul Phillips <paulp@improving.org> wrote:

On Wed, Feb 1, 2012 at 4:00 AM, Eugene Burmako <eugene.burmako@epfl.ch> wrote:
> Subj. always returns null, even on valid package names (e.g. when I try to
> load one of the $lineXXX packages defined by REPL). Shall I submit a bug?

I don't think anyone ever wanted this before.  I still don't know what
you'd want it for, but I implemented it for you in b2a21c4eac on the
theory that there's some interesting reason.

In short, when performing classToType over a class defined in a REPL,
reflection traverses the owners chain up to the $lineXXX package. Then
it tries to get Java package by that name and fails, since AFCL
doesn't support this abstraction. My changeset makes AFCL
automatically expose its virtual file system as a hierarchy of
packages. Btw, do you like the implementation?

On Feb 1, 7:33 pm, Eugene Burmako wrote:
> Ouch, I also implemented this stuff inhttps://github.com/scalamacros/kepler/commit/7d6637c024ec2d6d4a47ec2a....
> The changeset also sheds some light on potential applicability areas.
>
> On 1 February 2012 19:29, Paul Phillips wrote:
>
>
>
> > On Wed, Feb 1, 2012 at 4:00 AM, Eugene Burmako
> > wrote:
> > > Subj. always returns null, even on valid package names (e.g. when I try
> > to
> > > load one of the $lineXXX packages defined by REPL). Shall I submit a bug?
>
> > I don't think anyone ever wanted this before.  I still don't know what
> > you'd want it for, but I implemented it for you in b2a21c4eac on the
> > theory that there's some interesting reason.

On Wed, Feb 1, 2012 at 10:33 AM, Eugene Burmako wrote:
> Ouch, I also implemented this stuff in
> https://github.com/scalamacros/kepler/commit/7d6637c024ec2d6d4a47ec2a684....
> The changeset also sheds some light on potential applicability areas.

Ah.  No big deal, but we should get better at avoiding that. I like
the thing they do at github where they all push with some frequency to
named branches, so whenever you fetch your remotes you see a diffstat
summarizing what everyone has done recently.

http://scottchacon.com/2011/08/31/github-flow.html

I don't see any obvious issues with the implementation. (That's
pretty close to the nicest thing I say about code most days, to give
you a little context.)

Githubs idea sounds very reasonable. Would be great to adopt similar process so that we could all share scala/scala repo.

On 1 February 2012 19:52, Paul Phillips <paulp@improving.org> wrote:

On Wed, Feb 1, 2012 at 10:33 AM, Eugene Burmako <eugene.burmako@epfl.ch> wrote:
> Ouch, I also implemented this stuff in
> https://github.com/scalamacros/kepler/commit/7d6637c024ec2d6d4a47ec2a684783f5943f0c22#diff-1.
> The changeset also sheds some light on potential applicability areas.

Ah.  No big deal, but we should get better at avoiding that.  I like
the thing they do at github where they all push with some frequency to
named branches, so whenever you fetch your remotes you see a diffstat
summarizing what everyone has done recently.

 http://scottchacon.com/2011/08/31/github-flow.html

I don't see any obvious issues with the implementation.  (That's
pretty close to the nicest thing I say about code most days, to give
you a little context.)