[DUG] unit source code size
Paul Heinz
paul at accredo.co.nz
Mon Jul 5 20:13:17 NZST 2010
Jolyon wrote:
Whilst I agree with the rest of your comments about keeping forms and
business objects separate - this one caught my attention:
> This facility was afaik originally created to fix a
> shortcoming in .NET which was the lack of separate resource
> files to store form designs (i.e. no DFM's). Form designs
> were expressed as procedural code to construct the form
> object controls etc, and thus required an IDE/tool maintained
> section to be embedded in your application source code.
Personally, I don't see this as a shortcoming of .NET - I think it's an
improvement. Storing .DFMs as a weakly bytecoded stream of constructors
and property assignments in a separate pseudo-interpreter always struck
me as a wart of Delphi - something it 'inherited' from VB's design
without reconsidering it in the clear light of day. As least they
partially saw the light and switched to text .DFMs which are only
converted to bytecode at link time.
Delphi could have always generated .DFMs as Delphi source code instead
which it compiled and included. The advantages to .DFMs being a bytecode
interpreted resource format always seemed pretty minimal to me. Frames,
form inheritance and other later additions would likely have been a fair
bit less awkward and fragile too.
So it doesn't surprise me that Anders took the opportunity to revisit
that design decision when he designed .NET.
Cheers,
Paul.
More information about the Delphi
mailing list