Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail
From: BGB <cr88192@hotmail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Why "lock" functionality is introduced for all the objects?
Date: Tue, 28 Jun 2011 21:14:16 -0700
Organization: albasani.net
Lines: 29
Message-ID: <iue924$da9$1@news.albasani.net>
References: <d0bb9e06-16f0-4282-a37e-47e9ca9630ec@r2g2000vbj.googlegroups.com> <iuce66$2nh$1@news.albasani.net> <iud083$2jr$1@news.onet.pl> <iudelj$d4j$1@news.albasani.net> <iudsh3$6fd$2@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.albasani.net TIKJxY9cE0j93+pb1DW0fx+CTN2g8nqSOtr9aVWiKQWGEve6olnmRHjVFOoLny+icNF6uQ6beFysVJZUSTJG0g9+JtMSTNPEfhitXgnb1S5/QvsdfS6N46dDUpKqh6xQ
NNTP-Posting-Date: Wed, 29 Jun 2011 04:18:13 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="ttHGjGZaNzpS7dzLOuuNZjC2B7vkfAAjYsl1nCW0OCZqAZschAvB4Yrqb5gjNo55hrvKmyup+CCzyDJf7MFUGJolafMIoehvuIehhQCE87rdnqFh+KUBN29fJ2C+v0bK"; mail-complaints-to="abuse@albasani.net"
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
In-Reply-To: <iudsh3$6fd$2@dont-email.me>
Cancel-Lock: sha1:5mtQ4BQo6b4D9tTPbKHdcUvI9j4=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5759

On 6/28/2011 5:43 PM, Eric Sosman wrote:
> On 6/28/2011 4:43 PM, BGB wrote:
>> [...]
>> they made every object lockable but not every object cloneable, where
>> one would think cloning would be generally a higher priority.
>
> class MySingleton implements Cloneable {
> // What's wrong with this picture?
> }
>

makes about as much sense as the ability to lock every object, including 
those where locking is not exactly sane or useful...

to be strictly sensible, one would have to do something special for 
lockable objects as well as cloneable ones...


it is like in ActionScript, which requires a special modifier for 
dynamic objects, even though one could allow people to freely shove 
custom fields and methods into instances of any object.

it made more sense to support non-dynamic objects as well, and actually 
have these as the default case (whereas it probably would have been less 
effort implementation-wise to simply only have dynamic objects and 
optimize the non-dynamic use cases).


or such...