Re: synchronized/wait/notify on AnyRef

On Wed, Feb 11, 2009 at 8:10 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Then people wanting to do these things with Scala objects would be told "sorry, you have to use Java for that".  If you can't see why that's undesirable, well, I'll run away.

You mean synchronize on an arbitrary Scala object IN Java? Well, since a Scala object is a java.lang.Object, in Java you would be able to do that. I just don't see the need to expose that on AnyRef when programming in Scala.
If you meant something else, please clarify.

If you're using a Java library/framework in Scala, which is quite common, then that library/framework may very well expect you to synchronize on an "arbitrary" object.

On Wed, Feb 11, 2009 at 9:16 AM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

On Wed, Feb 11, 2009 at 8:10 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Then people wanting to do these things with Scala objects would be told "sorry, you have to use Java for that".  If you can't see why that's undesirable, well, I'll run away.

You mean synchronize on an arbitrary Scala object IN Java? Well, since a Scala object is a java.lang.Object, in Java you would be able to do that. I just don't see the need to expose that on AnyRef when programming in Scala.
If you meant something else, please clarify.

--
http://erikengbrecht.blogspot.com/

On Wed, Feb 11, 2009 at 8:28 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

If you're using a Java library/framework in Scala, which is quite common, then that library/framework may very well expect you to synchronize on an "arbitrary" object.

If you pass a Scala object to the Java framework it will see it as a java.lang.Object and be able to synchronize on it.

Then people wanting to do these things with Scala objects would be told "sorry, you have to use Java for that".  If you can't see why that's undesirable, well, I'll run away.

2009/2/11 Nils Kilden-Pedersen <nilskp@gmail.com>

On Wed, Feb 11, 2009 at 7:58 AM, David MacIver <david.maciver@gmail.com> wrote:

Well, because scala.AnyRef == java.lang.Object, so those methods are
supported by all AnyRefs rather than provided by a trait.

That's an implementation detail. That doesn't mean that everything on java.lang.Object should be exposed on AnyRef.

I am not rewriting bar, I am using bar. That's why the code I showed
didn't define bar.

2009/2/11 Nils Kilden-Pedersen :
> On Wed, Feb 11, 2009 at 8:26 AM, Ricky Clarkson
> wrote:
>>
>> Imagine I'm porting some code from Java to Scala, and I have
>> synchronized(bar) { foo } in my Java code.
>
> If bar is a Java class, you can do that. If you're rewriting bar to a Scala
> class, you need to have that Scala class implement the fictitious
> Lock/Monitor/Whatever trait. Why would that be hard?
>

Allow me to provide emphasis:

>> then that library/framework may very well expect ***YOU*** to synchronize on an
>> "arbitrary" object.

Imagine I'm porting some code from Java to Scala, and I have
synchronized(bar) { foo } in my Java code. When I get to Scala, I
can't do anything semantically equal to that because a committer
listened to you. So I ask on the mailing list and get told, sorry,
you'll have to write that bit in Java, as it's stupid and therefore
you can't do it in Scala.

2009/2/11 Nils Kilden-Pedersen :
> On Wed, Feb 11, 2009 at 8:10 AM, Ricky Clarkson
> wrote:
>>
>> Then people wanting to do these things with Scala objects would be told
>> "sorry, you have to use Java for that". If you can't see why that's
>> undesirable, well, I'll run away.
>
> You mean synchronize on an arbitrary Scala object IN Java? Well, since a
> Scala object is a java.lang.Object, in Java you would be able to do that. I
> just don't see the need to expose that on AnyRef when programming in Scala.
> If you meant something else, please clarify.
>

On Wed, Feb 11, 2009 at 8:39 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Allow me to provide emphasis:

>> then that library/framework may very well expect ***YOU*** to synchronize on an
>> "arbitrary" object.

Ok, got it. Well, I think that's a very theoretic example, almost to the point of being a straw man. Why couldn't that Scala object extend my fictitious trait?

Yes, but what if the framework expects you to synchronize on the object?

On Wed, Feb 11, 2009 at 9:35 AM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

On Wed, Feb 11, 2009 at 8:28 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

If you're using a Java library/framework in Scala, which is quite common, then that library/framework may very well expect you to synchronize on an "arbitrary" object.

If you pass a Scala object to the Java framework it will see it as a java.lang.Object and be able to synchronize on it.

--
http://erikengbrecht.blogspot.com/

On Wed, Feb 11, 2009 at 8:47 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

And screw your strawman nonsense. 

I already conceded the point, so no need to get offensive.

On Wed, Feb 11, 2009 at 8:26 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Imagine I'm porting some code from Java to Scala, and I have
synchronized(bar) { foo } in my Java code.

If bar is a Java class, you can do that. If you're rewriting bar to a Scala class, you need to have that Scala class implement the fictitious Lock/Monitor/Whatever trait. Why would that be hard?

Because it's not a Scala object. I am using a non-Scala object within
Scala and would like to synchronise on it.

And screw your strawman nonsense. There are many other situations.
This is an 'example'.

2009/2/11 Nils Kilden-Pedersen :
> On Wed, Feb 11, 2009 at 8:39 AM, Ricky Clarkson
> wrote:
>>
>> Allow me to provide emphasis:
>>
>> >> then that library/framework may very well expect ***YOU*** to
>> >> synchronize on an
>> >> "arbitrary" object.
>
> Ok, got it. Well, I think that's a very theoretic example, almost to the
> point of being a straw man. Why couldn't that Scala object extend my
> fictitious trait?
>

On Wed, Feb 11, 2009 at 8:56 AM, James Iry <jamesiry@gmail.com> wrote:

Any implicit conversion would have to be compiler magic rather than a normal implicit. 

Yes, I didn't mean the normal implicit, but certainly compiler magic, which the Scala compiler is no stranger to.
 

And with such a magic implicit conversion globally available we've really changed nothing - every object is effectively a monitor.

Since every Scala object is a java.lang.Object this will always be true. I was merely referring what's exposed in the API.

On Wed, Feb 11, 2009 at 8:41 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

I am not rewriting bar, I am using bar.  That's why the code I showed
didn't define bar.

I see what you mean. I guess that's a valid point, although one would think that some sort of implicit conversion could solve that.

I consider "strawman" to be just as offensive as "screw" in debate.
After someone goes to effort to explain a case to you, making it more
and more specific as you miss the point ever more finely, to then say
it is a strawman case is a bit, um, counterproductive.

2009/2/11 Nils Kilden-Pedersen :
> On Wed, Feb 11, 2009 at 8:47 AM, Ricky Clarkson
> wrote:
>>
>> And screw your strawman nonsense.
>
> I already conceded the point, so no need to get offensive.
>

Except that implicit conversions create new objects and I need to lock on the object handed me by the third party library.  Any implicit conversion would have to be compiler magic rather than a normal implicit.  And with such a magic implicit conversion globally available we've really changed nothing - every object is effectively a monitor.

On Wed, Feb 11, 2009 at 6:45 AM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

On Wed, Feb 11, 2009 at 8:41 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

I am not rewriting bar, I am using bar.  That's why the code I showed
didn't define bar.

I see what you mean. I guess that's a valid point, although one would think that some sort of implicit conversion could solve that.

On Wed, Feb 11, 2009 at 9:12 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

I consider "strawman" to be just as offensive as "screw" in debate.
After someone goes to effort to explain a case to you, making it more
and more specific as you miss the point ever more finely, to then say
it is a strawman case is a bit, um, counterproductive.

I don't know that I agree with that. In any kind of debate, one can come up with reasons for anything. Some of those are straw men if they are too far fetched. Then they don't really contribute to the debate, but rather muddy the waters.

Regardless, my post was never meant to lobby for any kind of change to AnyRef, it's far too late for that obviously. I was just interested in the background, and I think that has been answered.

Thanks