reflectModule vs reflectSingleton vs reflectObject vs ...

214 views
Skip to first unread message

Eugene Burmako

unread,
Jul 19, 2012, 12:28:49 PM7/19/12
to scala-internals
Hi folks,

We've been thinking how to name a family of functions in reflection
that work with objects (aka modules in compiler speak). A few
examples: staticModule, reflectModule, ModuleSymbol etc.

There's a concern that module would be ambiguous because of the
associations with packaging, OSGI and stuff. Hence we're looking into
the alternative names we could use. WDYT?

Cheers,
Eugene

Paul Phillips

unread,
Jul 19, 2012, 12:33:39 PM7/19/12
to scala-i...@googlegroups.com
"module" has the advantage of being less ambiguous than "object", but then, so is everything else.

How about "singleton" or "single".

And, I know that technically "companion" can be a class or object, but I bet most people share my difficulty in thinking of "companion" as anything but the object, so... other than the mostly theoretical ambiguity with the companion class, this has the advantage of being a nice scala-specific term.

Simon Ochsenreither

unread,
Jul 19, 2012, 12:34:32 PM7/19/12
to scala-i...@googlegroups.com
I would strongly prefer exposing "object" (or where appropriate "singleton") to the outside.

I completely agree with you that "module" should be reserved for modularization stuff like OSGi or Jigsaw (if it ever arrives).

Adriaan Moors

unread,
Jul 19, 2012, 12:38:14 PM7/19/12
to scala-i...@googlegroups.com
isn't 'module' the legacy term (as in 'originated somewhere in the last decade') for 'object'?

Sadly, I don't like any of these: staticObject, reflectObject, ObjectSymbol

(replying to Paul) 'companion' is only applicable to classes/objects that have met their synonym,
so single objects shouldn't be called companions

Paul Phillips

unread,
Jul 19, 2012, 12:44:53 PM7/19/12
to scala-i...@googlegroups.com
On Thu, Jul 19, 2012 at 9:38 AM, Adriaan Moors <adriaa...@epfl.ch> wrote:
isn't 'module' the legacy term (as in 'originated somewhere in the last decade') for 'object'?

Yes.
 
Sadly, I don't like any of these: staticObject, reflectObject, ObjectSymbol

I think these would be a big mistake.  No name with "object" in it will ever be clear.
 
(replying to Paul) 'companion' is only applicable to classes/objects that have met their synonym,
so single objects shouldn't be called companions

Potential Companion?

Companion-In-Waiting?

Lonely Object looking for Good Time?

√iktor Ҡlang

unread,
Jul 19, 2012, 12:46:23 PM7/19/12
to scala-i...@googlegroups.com
DollarModuleDollar 



--
Viktor Klang

Akka Tech Lead
Typesafe - The software stack for applications that scale

Twitter: @viktorklang

Eugene Burmako

unread,
Jul 19, 2012, 12:52:45 PM7/19/12
to scala-i...@googlegroups.com
I'd go with this one

Simon Ochsenreither

unread,
Jul 19, 2012, 1:00:42 PM7/19/12
to scala-i...@googlegroups.com
I guess I need a new keyboard now ...

I'd go with this one

DollarModuleDollar

YMMD :-)

Daniel Sobral

unread,
Jul 19, 2012, 1:50:51 PM7/19/12
to scala-i...@googlegroups.com
On PinS, there are referred to as "Singleton Object", of which
"Companion Object" and "StandAlone Object" are special cases. Quoting:

singleton object

An object defined with the object keyword. Each singleton object has
one and only one instance. A singleton object that shares its name
with a class, and is defined in the same source file as that class, is
that class’s companion object. The class is its companion class. A
singleton object that doesn’t have a companion class is a standalone
object.

http://docs.scala-lang.org/glossary/

So I prefer Singleton, since that's what's actually documented.
--
Daniel C. Sobral

I travel to the future all the time.

Matthew Pocock

unread,
Jul 21, 2012, 10:29:29 AM7/21/12
to scala-i...@googlegroups.com
On 19 July 2012 18:50, Daniel Sobral <dcso...@gmail.com> wrote:

http://docs.scala-lang.org/glossary/

So I prefer Singleton, since that's what's actually documented.

What would the methods look like to resolve a Singleton to a Companion, in the case where it is a companion object? I agree - Singleton keeps the naming much more consistent, I'm just wondering what the knock-on effect as a user of the API would be, and if there's anything else that needs a rename because of this.

Matthew
 

--
Daniel C. Sobral

I travel to the future all the time.



--
Dr Matthew Pocock
Integrative Bioinformatics Group, School of Computing Science, Newcastle University
skype: matthew.pocock
tel: (0191) 2566550

Simon Ochsenreither

unread,
Jul 21, 2012, 1:02:31 PM7/21/12
to scala-i...@googlegroups.com
If we are trying to standardize on a name, just wondering if MODULE$ and the REPL output (when defining an object) should be adapted, too.
Is there a deeper reasoning why "module" is used in these places, or are they just artifacts from earlier Scala versions (when "object" was still called "module")?

Paul Phillips

unread,
Jul 21, 2012, 2:20:57 PM7/21/12
to scala-i...@googlegroups.com


On Sat, Jul 21, 2012 at 10:02 AM, Simon Ochsenreither <simon.och...@googlemail.com> wrote:
If we are trying to standardize on a name, just wondering if MODULE$ and the REPL output (when defining an object) should be adapted, too.

Ha, it's funny the things to which one becomes blind.  I can't believe it's been printing "defined module Foo" all this time, but there it is.

Changing MODULE$ would inflict a great deal of breakage; there should be greater motivation than a general desire for orderliness.  Changing the repl, that's no problem.

Simon Ochsenreither

unread,
Jul 28, 2012, 10:02:35 AM7/28/12
to scala-i...@googlegroups.com
The responsible code for "defined module" is in MemberHandlers.scala.

Any decision yet whether ModuleHandler, ModuleDef and "module" should be renamed to ObjectHandler/ObjectDef/"object" vs. SingletonHandler/SingletonDef/"singleton" (or something else)?

I'm a bit concerned about "singleton" ... only top-level objects are "real" singletons, right? (It would probably work currently, because the console prints only top-level definitions anyway, but what if this changes in the future?)

Eugene Burmako

unread,
Jul 30, 2012, 1:05:13 PM7/30/12
to scala-i...@googlegroups.com
No progress on this one so far. I've created an issue for it to simplify tracking: https://issues.scala-lang.org/browse/SI-6156

Eugene Burmako

unread,
Aug 2, 2012, 11:57:53 AM8/2/12
to scala-internals
Folks, since there's no progress in finding a name that's noticeably
better than "module", we decided to keep it.

Personally I'd love to use Scala's natural terminology, but having
things named "reflectObject" or "ObjectSymbol" is very ambiguous.

Simon Ochsenreither

unread,
Aug 2, 2012, 1:20:19 PM8/2/12
to scala-i...@googlegroups.com
Just interest: Ambiguous to what?

Daniel Sobral

unread,
Aug 2, 2012, 1:39:09 PM8/2/12
to scala-i...@googlegroups.com
And what happened to Singleton?

Eugene Burmako

unread,
Aug 2, 2012, 3:06:16 PM8/2/12
to scala-internals
@Simon. Mirrors already have "reflect(x: Any): InstanceMirror". Adding
"reflectObject" next to that method would look weird.

@Daniel. "Singleton" isn't ambiguous w.r.t modularization stuff, but
it has its own problems. For example, the spec mentions singletons
only in context of singleton types (whereas "module" is explicitly
introduced as a synonym for "object"). And we also have SingletonTypes
in the API, which can express other things than types of modules.
Hence "singleton" isn't very much better than "module", which doesn't
justify the hassle of renaming.

Simon Ochsenreither

unread,
Aug 3, 2012, 12:32:53 PM8/3/12
to scala-i...@googlegroups.com
Sorry to bring it up again, but I think keeping “module” here is really unfortunate and will hunt us for years to come.

Of course it is not great that most people with a Java background equate “object” with “instance”, but we already live with that problem for a long time.

We shouldn't pile slightly unfortunate naming choices upon slightly unfortunate naming choices. I think the amount of people who know that “module” was the ancient name of Scala's “object” can be counted with a few hands. It is some interesting trivia, but shouldn't affect an API which we expose to users.

In my opinion, we should start cleaning up our stuff e. g. going through our documentation and identifying were we confused “object” with “instance”, but retreating to yet-another-name is not a great solution.

Especially “module” ... we will hate us for that naming decision as soon as a module system (either Java's or our own comes around the corner). It will probably force us to make the next “slightly unfortunate” naming choice in the future.

If we choose “module” know, what will be the name of the module system in X years?

Let's avoid technical debt where it is clearly anticipatable.

Thanks and bye,

Simon

Alex Cruise

unread,
Aug 3, 2012, 1:16:08 PM8/3/12
to scala-i...@googlegroups.com
On Fri, Aug 3, 2012 at 9:32 AM, Simon Ochsenreither
<simon.och...@googlemail.com> wrote:
> Sorry to bring it up again, but I think keeping “module” here is really
> unfortunate and will hunt us for years to come.

Personally, I think the best course of action is to change
user-visible messages (e.g. "Defined module Foo") to read "object"
instead, and leave the internal identifiers alone, at least until
anyone can come up with better names. :)

-0xe1a

Simon Ochsenreither

unread,
Aug 3, 2012, 2:02:35 PM8/3/12
to scala-i...@googlegroups.com
Hi Alex,


Personally, I think the best course of action is to change
user-visible messages (e.g. "Defined module Foo") to read "object"
instead,
Sure.

and leave the internal identifiers alone, at least until
anyone can come up with better names. :)
I think “object” is reasonable, considering that the name is identical with the corresponding keyword.

As long as the identifiers are purely internal, the names can be completely arbitrary, I don't care much. I just fear that they will leak (or have they already?) into the reflection API over time and then we will be stuck with it for a very long time.

My proposal is basically to give it a consistent name everywhere:

keyword == REPL message == compiler API == reflection API == documentation

Thanks and bye!

Simon

Simon Ochsenreither

unread,
Aug 3, 2012, 2:15:21 PM8/3/12
to scala-i...@googlegroups.com

I just fear that they will leak (or have they already?) into the reflection API over time and then we will be stuck with it for a very long time.

Looks like it is in scala.reflect.base :-(

(Btw: tpe, actualTpe and staticTpe: Is a better name for type than tpe? I guess everyone thought about that already ... what's the status?)

Paul Phillips

unread,
Aug 3, 2012, 3:06:12 PM8/3/12
to scala-i...@googlegroups.com
On Fri, Aug 3, 2012 at 11:15 AM, Simon Ochsenreither <simon.och...@googlemail.com> wrote:
(Btw: tpe, actualTpe and staticTpe: Is a better name for type than tpe? I guess everyone thought about that already ... what's the status?)

There's not a better name for type than tpe unless it's `type` (which is not better)  but that's no reason to have methods called "actualTpe" and "staticTpe" in the api.  The inability to use "type" as an identifier is not viral, it doesn't infect any of its cousins.

  def actualType
  def staticType

Those are IMO clear improvements.

Jan Vanek

unread,
Aug 3, 2012, 5:51:21 PM8/3/12
to scala-i...@googlegroups.com
On 03.08.2012 18:32, Simon Ochsenreither wrote:
> Sorry to bring it up again, but I think keeping “module” here is
> really unfortunate and will hunt us for years to come.
>
> Of course it is not great that most people with a Java background
> equate “object” with “instance”, but we already live with that problem
> for a long time.
>
> We shouldn't pile slightly unfortunate naming choices upon slightly
> unfortunate naming choices. I think the amount of people who know that
> “module” was the ancient name of Scala's “object” can be counted with
> a few hands. It is some interesting trivia, but shouldn't affect an
> API which we expose to users.
>

I think reflectObject is the right Scala name. Is there someone with
Java background who prefers "module" over "object"? :-)

With regards,
Jan

martin odersky

unread,
Aug 3, 2012, 5:58:44 PM8/3/12
to scala-i...@googlegroups.com
On Fri, Aug 3, 2012 at 11:51 PM, Jan Vanek <j3v...@gmail.com> wrote:
On 03.08.2012 18:32, Simon Ochsenreither wrote:
Sorry to bring it up again, but I think keeping “module” here is really unfortunate and will hunt us for years to come.

Of course it is not great that most people with a Java background equate “object” with “instance”, but we already live with that problem for a long time.

We shouldn't pile slightly unfortunate naming choices upon slightly unfortunate naming choices. I think the amount of people who know that “module” was the ancient name of Scala's “object” can be counted with a few hands. It is some interesting trivia, but shouldn't affect an API which we expose to users.


I think reflectObject is the right Scala name. Is there someone with Java background who prefers "module" over "object"? :-)

Object will definitely not work, as it confuses the definition form with the instance. The only possibility I can see is "singleton". But, it's a huge change that will affect 100s of files and will no doubt cause weeks of incompatibilty problems. Not sure it will be worth the trouble.

Cheers

 - Martin


 

With regards,
Jan


In my opinion, we should start cleaning up our stuff e. g. going through our documentation and identifying were we confused “object” with “instance”, but retreating to yet-another-name is not a great solution.

Especially “module” ... we will hate us for that naming decision as soon as a module system (either Java's or our own comes around the corner). It will probably force us to make the next “slightly unfortunate” naming choice in the future.

If we choose “module” know, what will be the name of the module system in X years?

Let's avoid technical debt where it is clearly anticipatable.

Thanks and bye,

Simon




--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

Simon Ochsenreither

unread,
Aug 3, 2012, 6:19:20 PM8/3/12
to scala-i...@googlegroups.com
Hi Martin!


Object will definitely not work, as it confuses the definition form with the instance.
 
Aren't we living with that since the keyword "module" was changed to "object" years ago?
Imho telling people that "instance" != "object" is a one-time cost, but keeping inconsistent naming around will a debt to everyone.
I don't think having consistent naming will make it any worse than it is currently.

 
The only possibility I can see is "singleton". But, it's a huge change that will affect 100s of files and will no doubt cause weeks of incompatibilty problems. Not sure it will be worth the trouble.

I think it would work if the public parts of the reflection API are fixed, the rest can be deprecated until code depending on compiler internals has been fixed. But it would not be great to release a new reflection API in which code is already deprecated.

Just my few cents ...

Thanks and bye!

Simon

Simon Ochsenreither

unread,
Aug 3, 2012, 6:22:15 PM8/3/12
to scala-i...@googlegroups.com
Hi Paul,


There's not a better name for type than tpe unless it's `type` (which is not better)  
I assume every other option has already been considered (toType, getType, asType, etc.)?
 
but that's no reason to have methods called "actualTpe" and "staticTpe" in the api.  The inability to use "type" as an identifier is not viral, it doesn't infect any of its cousins.
 Yes, that's what I meant! :-)


Thanks and bye!

Simon

Paul Phillips

unread,
Aug 3, 2012, 6:47:12 PM8/3/12
to scala-i...@googlegroups.com


On Fri, Aug 3, 2012 at 3:22 PM, Simon Ochsenreither <simon.och...@googlemail.com> wrote:
I assume every other option has already been considered (toType, getType, asType, etc.)?

Every other option has been considered.

(Would you believe someone who says "every other option has been considered.")

Learning that "tpe" means "type" is a one time cost.  Gratuitously deviating from the established conventions in the compiler would plague us with annoyance for years to come.  I already want to cry every time I have to remember where I am and whether it is "decls" or "declarations", "info" or the mouthful "typeSignature", where "ownerChain" and other common methods have gone to, and so on.

Eugene Burmako

unread,
Aug 4, 2012, 3:44:39 AM8/4/12
to scala-internals
https://github.com/scala/scala/pull/1046

On Aug 4, 12:47 am, Paul Phillips <pa...@improving.org> wrote:
> On Fri, Aug 3, 2012 at 3:22 PM, Simon Ochsenreither <
>

Jan Vanek

unread,
Aug 4, 2012, 12:19:20 PM8/4/12
to scala-i...@googlegroups.com
On 8/3/12, martin odersky <martin....@epfl.ch> wrote:
> On Fri, Aug 3, 2012 at 11:51 PM, Jan Vanek <j3v...@gmail.com> wrote:
>
>> On 03.08.2012 18:32, Simon Ochsenreither wrote:
>>
>>> Sorry to bring it up again, but I think keeping “module” here is really
>>> unfortunate and will hunt us for years to come.
>>>
>>> Of course it is not great that most people with a Java background equate
>>> “object” with “instance”, but we already live with that problem for a
>>> long
>>> time.
>>>
>>> We shouldn't pile slightly unfortunate naming choices upon slightly
>>> unfortunate naming choices. I think the amount of people who know that
>>> “module” was the ancient name of Scala's “object” can be counted with a
>>> few
>>> hands. It is some interesting trivia, but shouldn't affect an API which
>>> we
>>> expose to users.
>>>
>>>
>> I think reflectObject is the right Scala name. Is there someone with Java
>> background who prefers "module" over "object"? :-)
>>
>
> Object will definitely not work, as it confuses the definition form with
> the instance. The only possibility I can see is "singleton". But, it's a
> huge change that will affect 100s of files and will no doubt cause weeks of
> incompatibilty problems. Not sure it will be worth the trouble.
>

Coming from Java... Some minimal coding... How the ... do I write
static method... What? No statics?... object.. what? wtf?...
hardcoded??... after a while... it's kind of cool... after a while...
how do I write my cool constructors?... what? impossible?... ahh...
companion object... perfect...

Everyone with minimal experience learns very very soon about Scala's
object, and that the name "object" has its Scala specific semantics.
Of course it collides with instance in a way, but everyone is aware of
it already. Having reflectObject is only consequent. Even if we say
the keyword object is confusing, adding reflectObject adds exactly
zero to the confusion.

Not coming from Java... keyword object, method reflectObject... OK

--

Well, my limited view... Put on scale:
reflectObject 10
reflectSingleton 7-8
reflectModule 1

In my immodest opinion, if reflectObject doesn't do, reflectSingleton
is still worth the trouble.

With regards,
Jan

> Cheers
>
> - Martin
>
>
>
>
>>
>> With regards,
>> Jan
>>
>>
>> In my opinion, we should start cleaning up our stuff e. g. going through
>>> our documentation and identifying were we confused “object” with
>>> “instance”, but retreating to yet-another-name is not a great solution.
>>>
>>> Especially “module” ... we will hate us for that naming decision as soon
>>> as a module system (either Java's or our own comes around the corner).
>>> It
>>> will probably force us to make the next “slightly unfortunate” naming
>>> choice in the future.
>>>
>>> If we choose “module” know, what will be the name of the module system
>>> in
>>> X years?
>>>
>>> Let's avoid technical debt where it is clearly anticipatable.
>>>
>>> Thanks and bye,
>>>
>>> Simon
>>>
>>
>>
>
>
> --
> Martin Odersky
> Prof., EPFL <http://www.epfl.ch> and Chairman,
> Typesafe<http://www.typesafe.com>

Simon Ochsenreither

unread,
Aug 6, 2012, 1:50:53 PM8/6/12
to scala-i...@googlegroups.com
I created a pull request changing the REPL output from “module” to “object”: https://github.com/scala/scala/pull/1058

Simon Ochsenreither

unread,
Aug 6, 2012, 2:54:27 PM8/6/12
to scala-i...@googlegroups.com
Hi everyone, hi Martin,



Object will definitely not work, as it confuses the definition form with the instance. The only possibility I can see is "singleton". But, it's a huge change that will affect 100s of files and will no doubt cause weeks of incompatibilty problems. Not sure it will be worth the trouble.

I sat down, went through the code and created a patch: https://github.com/scala/scala/pull/1065

All tests pass.

I left stuff like MODULE$ untouched, but I think I got everything else worth fixing. Of course, @deprecated “module” methods can still be added if third-party code depends too much on it

Currently, the patch replaces “module” with “object”, but I'm happy to change it to something better if there is anything which makes all people happy. :-)

After reading a bit of the compiler code, I think even the current change is a net win. No more module-is-object context switching. :-)

What do you think?

Thanks and bye,

Simon

Mirco Dotta

unread,
Aug 6, 2012, 3:52:20 PM8/6/12
to scala-i...@googlegroups.com
> I left stuff like MODULE$ untouched, but I think I got everything else worth fixing. Of course, @deprecated “module” methods can still be added if third-party code depends too much on it

Although I'm very supportive of renaming occurrences of `module` into `object`, please don't just trash the existing `module` methods (deprecation is good).

Paul Phillips

unread,
Aug 6, 2012, 4:31:06 PM8/6/12
to scala-i...@googlegroups.com


On Mon, Aug 6, 2012 at 11:54 AM, Simon Ochsenreither <simon.och...@googlemail.com> wrote:
>
> After reading a bit of the compiler code, I think even the current change is a net win. No more module-is-object context switching. :-)

Well, I wanted to like it.  Sorry, no such luck.  Every fear I might have about the confusion which accompanies "object" comes to pass.  Calling something an "object class", methods like "isObjectClass" not to mention "isObject" (which sounds like it means "descends from Object" as opposed to "isAnyVal") an icode class called  LOAD_OBJECT is impressively deceptive, what can one suppose a "sourceObject" is, etc. etc.

I'd rather change all the names to module than change them all to object (not that I'm proposing that.)

Simon Ochsenreither

unread,
Aug 6, 2012, 4:32:16 PM8/6/12
to scala-i...@googlegroups.com
Hi,


Although I'm very supportive of renaming occurrences of `module` into `object`, please don't just trash the existing `module` methods (deprecation is good).

right, I'll add them back were appropriate.

Thanks and bye,

Simon

Eugene Burmako

unread,
Aug 6, 2012, 4:33:16 PM8/6/12
to scala-internals
To tell the truth, I was very skeptical about your initiative, but the
pull request had me converted. Primary reason is that the changeset is
actually tiny in comparison with what I imagined (1.5kloc, come on).

By the way, why don't we want to rename MODULE$ to INSTANCE$? We can
break binary compatibility in 2.10, right?

On Aug 6, 8:54 pm, Simon Ochsenreither

martin odersky

unread,
Aug 6, 2012, 5:23:10 PM8/6/12
to scala-i...@googlegroups.com
I agree. isObject, isObjectClass is bad. I think now that we are that far in our attempts, we could still give Singleton a try. isSingleton, isSingletonClass would work, IMO. 

Cheers

- Martin

Simon Ochsenreither

unread,
Aug 6, 2012, 5:37:14 PM8/6/12
to scala-i...@googlegroups.com
Hi Paul,


Well, I wanted to like it.  Sorry, no such luck.  Every fear I might have about the confusion which accompanies "object" comes to pass.  Calling something an "object class", methods like "isObjectClass"

Yes, I agree that the name is unfortunate, but imho not the “Module”/“Object” part, but the “Class” part, considering that there is also “isClass”.

The good thing is that afaik those names are seldomly used in public code (are they even exposed to the public?), so we could change them to something very precise without needing to live with the object/module as before.
 
not to mention "isObject" (which sounds like it means "descends from Object" as opposed to "isAnyVal")
I thought about that, too.

What won me over is that there are imho various good names which we could use (compared to “module” where more or less every other name except “object” was not identical to the keyword “object”): isReference, isJavaLangObject, etc.


an icode class called  LOAD_OBJECT is impressively deceptive,
Yes, maybe this was a bit too much. What do you suggest?
 
 
I'd rather change all the names to module than change them all to object (not that I'm proposing that.)

I thought about that too in the beginning, but changing the keyword would be an absolute nightmare ... :-(

Additionally, I really want to free up “module” for the module system.

Thanks and bye,

Simon
 

Simon Ochsenreither

unread,
Aug 6, 2012, 5:39:43 PM8/6/12
to scala-i...@googlegroups.com
Hi Martin,
 
I agree. isObject, isObjectClass is bad. I think now that we are that far in our attempts, we could still give Singleton a try. isSingleton, isSingletonClass would work, IMO. 

wouldn't that exclude any non-top-level objects?

Thanks and bye,

Simon

Nils Kilden-Pedersen

unread,
Aug 6, 2012, 5:52:46 PM8/6/12
to scala-i...@googlegroups.com
I was just about to write the same thing. The notion that object == singleton is one of the big confounders of Scala.

Simon Ochsenreither

unread,
Aug 6, 2012, 6:29:09 PM8/6/12
to scala-i...@googlegroups.com
Hi Eugene,


To tell the truth, I was very skeptical about your initiative, but the
pull request had me converted. Primary reason is that the changeset is
actually tiny in comparison with what I imagined (1.5kloc, come on).
Well, I was concerned that it was too big ... but I remember that you genius-of-the-macro-universe broke GitHub's diff view with your pull request size, so you have to know better than me. :-)

By the way, why don't we want to rename MODULE$ to INSTANCE$? We can
break binary compatibility in 2.10, right?

Paul mentioned earlier:
Changing MODULE$ would inflict a great deal of breakage; there should be greater motivation than a general desire for orderliness.

I don't have any opinion on changing the flag stuff “<module>”, “<modulevar>”, etc. or the MODULE$ name, but I trust Paul's judgment of the situation.

Thanks and bye,

Simon

Mirco Dotta

unread,
Aug 7, 2012, 1:03:23 AM8/7/12
to scala-i...@googlegroups.com
> By the way, why don't we want to rename MODULE$ to INSTANCE$? We can
> break binary compatibility in 2.10, right?

I know MODULE$ is considered an implementation detail, but there is code out there that
uses it, so it would turn out to be a source incompatible change. My vote goes against doing
this.

Roland Kuhn

unread,
Aug 7, 2012, 2:10:02 AM8/7/12
to scala-i...@googlegroups.com, scala-i...@googlegroups.com
Seconded: Given that Java users have no choice but to rely on this name, it would be bad to change it without a very compelling reason.


Regards,

Roland Kuhn
Typesafe — The software stack for applications that scale
twitter: @rolandkuhn

martin odersky

unread,
Aug 7, 2012, 3:49:30 AM8/7/12
to scala-i...@googlegroups.com
It need not. Depends how you define singleton. Unique wrt to what?
One way of putting it is, if you have

  class C {
     object O { ... }
   }

   val c = new C

Then c.O is the single object with definition {...} in c, or if you name the "class" of O, O$, it is the single object with type c.O$. 

Cheers

 - Martin

√iktor Ҡlang

unread,
Aug 7, 2012, 4:20:03 AM8/7/12
to scala-i...@googlegroups.com
On Tue, Aug 7, 2012 at 9:49 AM, martin odersky <martin....@epfl.ch> wrote:


On Mon, Aug 6, 2012 at 11:39 PM, Simon Ochsenreither <simon.och...@googlemail.com> wrote:
Hi Martin,
 
I agree. isObject, isObjectClass is bad. I think now that we are that far in our attempts, we could still give Singleton a try. isSingleton, isSingletonClass would work, IMO. 

wouldn't that exclude any non-top-level objects?

It need not. Depends how you define singleton. Unique wrt to what?

Absolutely. No matter what you do things (= classes) are only unique per ClassLoader at best.

Cheers,
 
One way of putting it is, if you have

  class C {
     object O { ... }
   }

   val c = new C

Then c.O is the single object with definition {...} in c, or if you name the "class" of O, O$, it is the single object with type c.O$. 

Cheers

 - Martin




--
Viktor Klang

Akka Tech Lead
Typesafe - The software stack for applications that scale

Twitter: @viktorklang

Simon Ochsenreither

unread,
Feb 6, 2013, 1:51:56 PM2/6/13
to scala-i...@googlegroups.com
Hi Eugene, hi everyone,


To tell the truth, I was very skeptical about your initiative, but the
pull request had me converted. Primary reason is that the changeset is
actually tiny in comparison with what I imagined (1.5kloc, come on).

As suggested in the last PR, here is the new effort to finally solve this for 2.11: https://github.com/scala/scala/pull/2078

Thanks and bye,

Simon

Eugene Burmako

unread,
Feb 7, 2013, 10:25:10 AM2/7/13
to <scala-internals@googlegroups.com>
Hi Simon,

Thanks for all the work you put into this! Since we're currently in a few-days-before-an-rc mode, I suggest delaying the discussion until 2.10.1-RC1 is released.

Cheers,
Eugene


--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Simon Ochsenreither

unread,
Feb 7, 2013, 3:15:58 PM2/7/13
to scala-i...@googlegroups.com
Hi Eugene,


Thanks for all the work you put into this!

No problem. It's a pleasure. :-)


Since we're currently in a few-days-before-an-rc mode, I suggest delaying the discussion until 2.10.1-RC1 is released.

Alright, I'll ping the list after the RC again.

Thanks and bye,

Simon
Reply all
Reply to author
Forward
0 new messages