[fpc-devel] Opening FPC base classes
Hi, I am the author of MSEide+MSEgui, a Free Pascal development environment: http://sourceforge.net/projects/mseide-msegui/ MSEide+MSEgui is not Delphi compatible and handles some basic TComponent issues differently to Lazarus: http://www.lazarus.freepascal.org/ Is it possible to add protected //for toolkit access only property OwnerPrivate: TComponent read FOwner write FOwner; deprecated; property NamePrivate: TComponentName read FName write FName; deprecated; property ComponentsPrivate: TfpList read FComponents write FComponents; deprecated; property ComponentStatePrivate: TComponentState read FComponentState write FComponentState; deprecated; property FreeNotifiesPrivate: TFpList read FFreeNotifies write FFreeNotifies; deprecated; to TComponent in order other toolkits than Lazarus can fulfil their taskwithout the necessity of changes in the FPC RTL? TReader and TWriter are classes which normally are used by frameworks only. Is it possible to move all private fields of TFiler, TReader and TWriter to protected in order other toolkits than Lazarus can fulfil their task without the necessity of changes in the FPC RTL? Is it possible to add protected //for toolkit access only property HandlePrivate: THandle read FHandle write FHandle; deprecated; to THandleStream and protected //for toolkit access only property CapacityPrivate: PtrInt read FCapacity write FCapacity; deprecated; to TMemoryStream? Thank you very much, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Opening FPC base classes
On Mon, 23 Jul 2012, Martin Schreiber wrote: Hi, I am the author of MSEide+MSEgui, a Free Pascal development environment: http://sourceforge.net/projects/mseide-msegui/ MSEide+MSEgui is not Delphi compatible and handles some basic TComponent issues differently to Lazarus: http://www.lazarus.freepascal.org/ Is it possible to add protected //for toolkit access only property OwnerPrivate: TComponent read FOwner write FOwner; deprecated; property NamePrivate: TComponentName read FName write FName; deprecated; property ComponentsPrivate: TfpList read FComponents write FComponents; deprecated; property ComponentStatePrivate: TComponentState read FComponentState write FComponentState; deprecated; property FreeNotifiesPrivate: TFpList read FFreeNotifies write FFreeNotifies; deprecated; to TComponent in order other toolkits than Lazarus can fulfil their taskwithout the necessity of changes in the FPC RTL? These fields must remain private to ensure proper functioning of the component system. Too much depends on the proper functioning of the notification API and the owner/owned relations and its inherent memory management. We can discuss alternative solutions for the tasks you need to do, if you'd care to explain them in detail. TReader and TWriter are classes which normally are used by frameworks only. Is it possible to move all private fields of TFiler, TReader and TWriter to protected in order other toolkits than Lazarus can fulfil their task without the necessity of changes in the FPC RTL? No problems here, we can give protected access to all of these fields. Is it possible to add protected //for toolkit access only property HandlePrivate: THandle read FHandle write FHandle; deprecated; to THandleStream No problems here. We can do this as well, provided we can make the signature slightly different: protected Procedure SetHandle(AHandle : THandle); virtual; property HandlePrivate: THandle read SetHandle SetHandle will just set the FHandle fields, but I want a virtual setter so descendent classes get a chance to react on the change in case they need to. and protected //for toolkit access only property CapacityPrivate: PtrInt read FCapacity write FCapacity; deprecated; to TMemoryStream? TMemoryStream.Capacity is already read/write. Why do you think you need direct access to the field ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Opening FPC base classes
On Mon, 23 Jul 2012, Martin Schreiber wrote: On Monday 23 July 2012 15:31:42 michael.vancann...@wisa.be wrote: I don't see why you cannot do the same. It's perfectly possible to use the streaming system for both TComponent and other classes. All it takes is RTTI, which happens to be enabled in TPersistent. Because of integration of third party components. But you are probably right, it seems to be the time to leave FCL compatibility. The design of TPersistent/TComponent and the whole classes unit has been made by Borland so that it made the development of a concurrent IDE to Delphi as difficult as possible. I've never seen it as such. There is nothing special about the classes unit. It uses available RTTI in a certain way, that's it. You're free to create a system that uses the same RTTI in a completely different way, and build an eco system around this. That you then cannot use code that expects the functionality of the classes unit, is a consequence you must accept. I hope Free Pascal has not the same attitude. ;-) Well, for starters, I don't draw the same conclusion as you: You don't need to leave compatibility behind. IMO it is perfectly possible to design a streaming system that streams both TComponents as non-TComponents, given a few small changes to TFiler. That would allow you to re-use third-party TComponent descendents and still offer all the things you need in msegui/mseide. I see that as a useful extension, and you can always ask for changes that would make this possible. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Opening FPC base classes
On 23 July 2012 17:12, Martin Schreiber mse00...@gmail.com wrote: Guys, please take into consideration not only Martin but also Graeme,.. :) Graeme does not need it, fpGUI does not stream components, has no IDE... For good reason. I don't want the headaches of designing and supporting a full blown IDE. I also don't like the 2+ files per Form that Lazarus IDE or MSEide uses, and which requires streaming. So I created a Forms Designer that doesn't require streaming, saved me some headaches, but also brought about some new features like... only one file needed for a Form design, support for 1 or more Forms designed in a single code unit, etc.. And as Michael mentioned, tiOPF is the only framework I use (and helped develop) for ALL my database needs. tiOPF is even handy to use in non-database applications. And Michael is correct - it doesn't use TComponent or TPersistent at all. It does use RTTI extensively though. I do agree with Michael though that issues with FPC's class designs must be discussed on a case-by-case basis, otherwise you throw the whole class hierarchy/design out the window. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
