Yes, you are right, only class methods are a problem, so the schema really should say:
<method name="apply" allocation="class" final="true" /> etc. The listing in lfc-undeclared seems to a pretty random collection. On 2010-05-08, at 16:28, André Bargull wrote: > No, <state>#apply() and <state>#remove() aren't deprecated. They were > proposed to be deprecated, but the proposal wasn't accepted. > > apply() and call() as 'instance' methods could be allowed, only 'class' > methods are problematic, right? > > > On 5/8/2010 10:15 PM, P T Withington wrote: >> Isn't LzState/apply deprecated? I thought you were supposed to constrain >> `applied` instead? >> >> In which case, we could keep the warning. >> >> I agree with Henry, we were trying to help people. If you clobber >> apply/call, you could regret it later... >> >> On 2010-05-08, at 11:27, André Bargull wrote: >> >>> Both, "apply" and "call" are marked as final in lfc-undeclared.xml, is >>> there any reason for this decision? I know this question was already raised >>> in an earlier thread. >>> I'm working on LPP-8982, LPP-8983 and LPP-8986 and I think I've found a way >>> to fix these bugs, but unfortunately compiling an application will now >>> result in a compiler warning caused by<state>#apply(): >>>> trunk/WEB-INF/lps/schema/lfc.lzx:509:42: Method state.apply is overriding >>>> a superclass method of the same name which has been declared final >>> >>> The compiler warning is actually correct, if apply() is final it should not >>> be possible to declare a method named "apply" in<state>. So, should I just >>> remove those annotations from lfc-undeclared or add an ugly workaround to >>> the compiler or ...? >>> >>> >>> - André >>> >> >>
