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

Closed
scabug opened this issue Mar 16, 2011 · 6 comments
Closed

objects/classes inside package objects #4344

scabug opened this issue Mar 16, 2011 · 6 comments

Comments

@scabug
Copy link

scabug 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
Copy link
Author

scabug commented Mar 16, 2011

Imported From: https://issues.scala-lang.org/browse/SI-4344?orig=1
Reporter: @paulp
See #5954

@scabug
Copy link
Author

scabug 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
Copy link
Author

scabug 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
Copy link
Author

scabug commented Jan 20, 2014

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

@SethTisue
Copy link
Member

seems out of scope now for Scala 2

@SethTisue SethTisue closed this as not planned Won't fix, can't repro, duplicate, stale Oct 16, 2023
@joroKr21
Copy link
Member

I think they didn't consider inherited objects/classes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants