reflectModule vs reflectSingleton vs reflectObject vs ...

Showing 1-48 of 48 messages
reflectModule vs reflectSingleton vs reflectObject vs ... Eugene Burmako 7/19/12 9:28 AM
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
Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Paul Phillips 7/19/12 9:33 AM
"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.

Re: reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 7/19/12 9:34 AM
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).
Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Adriaan Moors 7/19/12 9:38 AM
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
Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Paul Phillips 7/19/12 9:44 AM


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?

Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... √iktor Klang 7/19/12 9:46 AM


DollarModuleDollar 



--
Viktor Klang

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

Twitter: @viktorklang

Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Eugene Burmako 7/19/12 9:52 AM
I'd go with this one
Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 7/19/12 10:00 AM
I guess I need a new keyboard now ...

I'd go with this one

DollarModuleDollar

YMMD :-)
Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Daniel Sobral 7/19/12 10:50 AM
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.

On Thu, Jul 19, 2012 at 1:28 PM, Eugene Burmako <eugene....@epfl.ch> wrote:
--
Daniel C. Sobral

I travel to the future all the time.
Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Matthew Pocock 7/21/12 7:29 AM


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
mob: +447535664143

Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 7/21/12 10:02 AM
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")?
Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Paul Phillips 7/21/12 11:20 AM


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.
Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 7/28/12 7:02 AM
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?)
Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Eugene Burmako 7/30/12 10:05 AM
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
Re: reflectModule vs reflectSingleton vs reflectObject vs ... Eugene Burmako 8/2/12 8:57 AM
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.

On Jul 30, 7:05 pm, Eugene Burmako <eugene.burm...@epfl.ch> wrote:
> 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
>
> On 28 July 2012 16:02, Simon Ochsenreither <
>
>
>
>
>
>
>
Re: reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 8/2/12 10:20 AM
Just interest: Ambiguous to what?
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Daniel Sobral 8/2/12 10:39 AM
And what happened to Singleton?
Re: reflectModule vs reflectSingleton vs reflectObject vs ... Eugene Burmako 8/2/12 12:06 PM
@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.

On Aug 2, 7:39 pm, Daniel Sobral <dcsob...@gmail.com> wrote:
> And what happened to Singleton?
>
>
>
>
>
>
>
>
>
Re: reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 8/3/12 9:32 AM
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
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Alex Cruise 8/3/12 10:16 AM
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
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 8/3/12 11:02 AM
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
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 8/3/12 11:15 AM

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?)
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Paul Phillips 8/3/12 12:06 PM


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.

Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... j3vanek 8/3/12 2:51 PM
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
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... martin 8/3/12 2:58 PM


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

Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 8/3/12 3:19 PM
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
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 8/3/12 3:22 PM
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
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Paul Phillips 8/3/12 3:47 PM


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.

Re: reflectModule vs reflectSingleton vs reflectObject vs ... Eugene Burmako 8/4/12 12:44 AM
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 <
>
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... j3vanek 8/4/12 9:19 AM
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>
> PSED, 1015 Lausanne, Switzerland
> Tel. EPFL: +41 21 693 6863
> Tel. Typesafe: +41 21 691 4967
>
Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 8/6/12 10:50 AM
I created a pull request changing the REPL output from “module” to “object”: https://github.com/scala/scala/pull/1058
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 8/6/12 11:54 AM
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
Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Mirco Dotta 8/6/12 12:52 PM
> 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).
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Paul Phillips 8/6/12 1:31 PM


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.)

Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 8/6/12 1:32 PM
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
Re: reflectModule vs reflectSingleton vs reflectObject vs ... Eugene Burmako 8/6/12 1:33 PM
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
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... martin 8/6/12 2:23 PM


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

Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 8/6/12 2:37 PM
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
 
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 8/6/12 2:39 PM
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
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Nils 8/6/12 2:52 PM
I was just about to write the same thing. The notion that object == singleton is one of the big confounders of Scala.
Re: reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 8/6/12 3:29 PM
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
Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... Mirco Dotta 8/6/12 10:03 PM
> 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.
Re: [scala-internals] reflectModule vs reflectSingleton vs reflectObject vs ... rkuhn 8/6/12 11:10 PM
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
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... martin 8/7/12 12:49 AM


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

Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... √iktor Klang 8/7/12 1:20 AM


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

Re: reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 2/6/13 10:51 AM
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
Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Eugene Burmako 2/7/13 7:25 AM
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.
 
 

Re: [scala-internals] Re: reflectModule vs reflectSingleton vs reflectObject vs ... Simon Ochsenreither 2/7/13 12:15 PM
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
More topics »