i think we're talking two different things ... if you have an empty superclass
constructor and you don't declare any constructors, then yes, there is an
implicit constructor created in your subclass that calls super (as well, if you
DO declare a constructor and there is an empty super constructor, implicitly a
super() is added to the top of your constructor). in this case, because the
anonymous subclass is declared as new ERXEC(os), it's actually calling the
ERXEC(ObjectStore) constructor (which I PRESUME java secretly added into your
subclass with a super(os) call -- this is a little different than a normal
class). However, Kieran's specifically talking about the
ERXEC.newEditingContext() factory method, which you're bypassing here by
explicitly subclassing ERXEC and instantiating the class directly.
ms
On Dec 3, 2009, at 2:45 PM, Ricardo J. Parada wrote:
> Don't subclasses have an implicit super() to invoke the super class
> constructor?
>
>
> On Dec 3, 2009, at 2:38 PM, Kieran Kelleher wrote:
>
>> True, but then I would be bypassing the EC factory, which just seems dirty,
>> but yes, this very good suggestion is an elegant way to do it for sure.
>>
>> On Dec 3, 2009, at 2:16 PM, Anjo Krank wrote:
>>
>>>> PS. And even the above is not perfect protection against an autolock if a
>>>> thread gets cpu execution delay between construction statement and the
>>>> ec.setCoalesceAutoLocks(false) statement. After setting safelocking props
>>>> to false, I should really check if the ec was autolocked and unlock it
>>>> before returning .... or even have an ERXEC constructor that takes a
>>>> safeLocking boolean param, but that would be two more undesired
>>>> constructors ....... so probably making isLockedInThread public (or
>>>> accessible using reflection) should do the trick.
>>>
>>> In that case, you'd be better with
>>>
>>> return new ERXEC(os) {
>>> public boolean useAutoLock() {return false;}
>>>
>>> public boolean coalesceAutoLocks() {return false;}
>>> };
>>>
>>> Cheers, Anjo
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com
>>>
>>> This email sent to kieran_li...@mac.com
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/rparada%40mac.com
>>
>> This email sent to rpar...@mac.com
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com
>
> This email sent to msch...@mdimension.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
