[Laszlo-dev] For Review: Change 20090225-dda-V Summary: do not drop 'void' return types

[Donald Anderson]

On Feb 27, 2009, at 12:11 PM, P T Withington wrote:

> I think you've gone overboard with the LFC changes.  In some places  
> the right fix is to make the method final, rather than remove the  
> declaration.

Most of these changes were made because the functions were overridden  
(or in one case called) inconsistently within the LFC.
So I needed to change something, either in the base class or inherited  
to make the LFC compile.  That said, I agree, some of them
could also be declared final to prevent outside overrides.  The other  
few changes (*SelectionManager) were made because the components
override the methods, so they can't be declared final.

> callJS should be final

LzBrowserService class is already marked final, so final on a method  
is redundant.

> the displayResult overrides should be final

I can do that, but maybe better to mark LzAS3DebugService and  
LzAS2DebugService classes as final?  There are a lot of
other methods in those classes marked as private in doc, but not final.
(hmm, looks like the doc doesn't know about 'final' classes.  do our  
compilers even enforce it?)

> All the interfaces that are marked as @access private should be  
> final (modulo them being overridden within the LFC -- they really  
> should be sealed, if there were such a notion).

Yeah, well we could mark some of the classes in LFC as final, at least  
the outer classes that aren't intended to be subclassed.
Maybe I should put into the SchemaBuilder (now maybe should be called  
SchemaBuilderAndChecker) the check you state here.
I think there are lots of violations.  Of course, having final on  
methods only carries real weight in SWF9 unless our compilers
enforce it too.

> Otherwise, approved.

I'll check in what I have with the displayResult marked final.  I do  
need to keep the other changes to get a working LFC.

- Don


> On 2009-02-26, at 12:16EST, Donald Anderson wrote:
>
>> Change 20090225-dda-V by dda at lester-2.local on 2009-02-25 16:39:47  
>> EST
>>   in /Users/dda/laszlo/src/svn/openlaszlo/trunk-b
>>   for http://svn.openlaszlo.org/openlaszlo/trunk
>>
>> Summary: do not drop 'void' return types
>>
>> New Features:
>>
>> Bugs Fixed: [LPP-7789] SWF9: void return-type dropped
>>
>> Technical Reviewer: ptw (pending)
>> QA Reviewer: (pending)
>> Doc Reviewer: (pending)
>>
>> Documentation:
>>
>> Release Notes:
>>
>> Details:
>> Parser.jjt
>>   Fixed a mistake that was setting the return type in the AST to  
>> null for any function declared as "void".
>>   Null really means 'no return type specified' and must be  
>> distinguished from simply "void".
>>   "void" is now set as the return type in the AST.  Since this  
>> effectively 'enables' :void
>>   return types to appear in SWF9, this gave a small ripple effect  
>> in the lfc as detailed below.
>>
>> LzReplicationManager.lzs
>> LzDatapointer.lzs
>> LzDatapath.lzs
>>   for override functions destroy(), construct(), setSelected(), $lzc 
>> $set_datapath(),
>>   the :void return type has been removed to be compatible with the  
>> function it overrides.
>>   This amounts to no change for anyone calling or overriding these  
>> functions,
>>   given that the bug's previous behavior was to effectively  
>> remove :void
>>
>> services/LzBrowser.lzs
>>   according to the doc callJS() 'optionally' returns a value (the  
>> DHTML version does), so its :void
>>   return type has been removed.  Again, no discernable change to  
>> the user, and it now matches its
>>   documentation.
>>
>> LzDataSelectionManager.lzs
>> LzSelectionManager.lzs
>>   public functions unselect(),clearSelection(),select() now  
>> have :void return type removed.
>>   Some of these may be overridden (without return types) by  
>> components.
>>
>> swf9/LzDebug.as
>> swf/LzDebug.as
>>   added :void to displayResult() to match LzDebugService.  This  
>> function is marked private in doc,
>>   so users should not be overriding this, and should be unaware of  
>> the change.
>>
>> LaszloView.lzs
>> LaszloCanvas.lzs
>>   added :void to __LZinstantiationDone() to match LzNode.  This  
>> function is also marked private in doc,
>>   so users should not be overriding this, and should be unaware of  
>> the change.
>>
>> ParseTreePrinter.java
>>   Fixed an informational message triggered by the -SS flag to lzc,  
>> so the exact filename generated for
>>   for debugging line annotations is shown.
>>
>>
>> Tests:
>>   Andre's test case now gives the proper error message.
>>
>>   {smokecheck,weather,lzpix} x {swf8,swf9,dhtml}
>>
>> Files:
>> M      WEB-INF/lps/lfc/services/LzBrowser.lzs
>> M      WEB-INF/lps/lfc/debugger/platform/swf/LzDebug.as
>> M      WEB-INF/lps/lfc/debugger/platform/swf9/LzDebug.as
>> M      WEB-INF/lps/lfc/views/LaszloView.lzs
>> M      WEB-INF/lps/lfc/views/LaszloCanvas.lzs
>> M      WEB-INF/lps/lfc/helpers/LzDataSelectionManager.lzs
>> M      WEB-INF/lps/lfc/helpers/LzSelectionManager.lzs
>> M      WEB-INF/lps/lfc/data/LzReplicationManager.lzs
>> M      WEB-INF/lps/lfc/data/LzDatapointer.lzs
>> M      WEB-INF/lps/lfc/data/LzDatapath.lzs
>> M      WEB-INF/lps/server/src/org/openlaszlo/sc/ParseTreePrinter.java
>> M      WEB-INF/lps/server/sc/src/org/openlaszlo/sc/Parser.jjt
>>
>> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20090225-dda-V.tar
>>
>>
>>
>> --
>>
>> Don Anderson
>> Java/C/C++, Berkeley DB, systems consultant
>>
>> voice: 617-306-2057
>> email: dda at ddanderson.com
>> www: http://www.ddanderson.com
>>
>>
>>
>>
>>
>


--

Don Anderson
Java/C/C++, Berkeley DB, systems consultant

voice: 617-306-2057
email: dda at ddanderson.com
www: http://www.ddanderson.com





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20090227/ee3e1b03/attachment.html