Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

objects/classes inside package objects #4344

Open
scabug opened this issue Mar 16, 2011 · 5 comments

Comments

@scabug
Copy link

commented Mar 16, 2011

Having just written this email, I am led to wonder if there's some reason we can't just lift classes and objects out of the package object into the package.

Don't put objects and classes in package objects.  It kind of works
sometimes, but it exposes you to these corner cases, and for no
gain: the best case is that it works like it would have if you'd
just put the objects/classes in the package.

Like this.

package object PkgObj {
       def hi(s: String) = s
}
package PkgObj {
  object App extends Application {
          println(hi("hello,world"))
  }
}

If you look at what is generated the way you had it you will see
why there is a problem.  To run a program the bytecode has to be
where it's supposed to be, no tricks.

ls -l PkgObj/
total 24
-rw-r--r--  1 paulp  wheel   498 Mar 16 09:31 package$$.class
-rw-r--r--  1 paulp  wheel  1076 Mar 16 09:31 package$$App$$.class
-rw-r--r--  1 paulp  wheel   683 Mar 16 09:31 package.class
@scabug

This comment has been minimized.

Copy link
Author

commented Mar 16, 2011

@scabug

This comment has been minimized.

Copy link
Author

commented Mar 22, 2011

@odersky said:
I'd prefer to keep this in limbo for a while. The reason is that, eventually (i.e. if someone decides to pick up that ball), classes in package objects might actually be interpreted as a public view of a like-named class in the package. And then anything definite we do with them now might lead to incompatibilities.

@scabug

This comment has been minimized.

Copy link
Author

commented Jul 10, 2013

@adriaanm said:
Unassigning as milestone deadline was reached.

@scabug

This comment has been minimized.

Copy link
Author

commented Jan 20, 2014

@retronym said:
Martin sounds amenable to the idea of lifting them into real classes in the package. This was based on two things:

  1. the fact that the further research into using package objects to better distinguish the inside/outside views of a package didn't and won't happen
  2. a hope that it makes package objects a bit easier to implement and spec

I'm a touch skeptical about point #2, as we still need the package object to hold vals, defs, and type aliases. But I support the change on the grounds that it offers a better story for binary compatibly moving things between package and package object (especially in the light of implicit classes that motivate people to do this).

@scabug

This comment has been minimized.

Copy link
Author

commented Jan 20, 2014

@retronym said:
See also #5954 for implementation issues (hopefully now solved) with objects/classes nested in package objects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.