Re: [fpc-devel] property syntax extension
Hello, fpc-developer list. As Events (i.e callbacks at the time being) are syntactically done as properties, could it be possible that property attributes on the long run could help implementing thread Events (i.e. a class fires an event not as a callback (usually using a the main thread, but if programmed like that using a thread it defines) but uses a thread the program that sets the handler property defines ? Here the programmer does not need to write code that passes the parameters to the thread: the RTL does all this dirty stuff, helping less advanced programmers to do threaded applications like it's usually done with ADA.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to force the child's constructor to call its parent constructor
Couldn't you check the ID in your after construction event and throw an exception if it's not set ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Michael Schnell wrote: programmed like that using a thread it defines) but uses a thread the program that sets the handler property defines ? Here the programmer does not need to write code that passes the parameters to the thread: the RTL does all this dirty stuff, helping less advanced programmers to do threaded applications like it's usually done with ADA.) Are you sure this would make things easier? Code in the handler needs to be thread safe. Starting a thread is very easy, with TThread? Or do you mean you want something like work queues? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to force the child's constructor to call its parent constructor
It is a run-time error but what I am looking for is an compile-time error. It is not sensible(for me) to raise an exception because of bad implementation. Thanks for you idea ;) Amir Michael Schnell wrote: Couldn't you check the ID in your after construction event and throw an exception if it's not set ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] SysUtils exception translation issues
Hi all, after we had that quite heated discussion in core, I decided to take matters into my own hand and come up with some useful proposal. But now I am looking at fpc2.2.0 sources for SysUtils and feel quite desperate. The thing is that I don't know if those are actual bugs, design decisions, or Delphi compatibility issues: 1) Strangely, runtime error 1 (invalid function number) is translated to EOutOfMemory. 2) Translation to I/O errors: there's a string set for RTE15, although it's not even handled by the case statement, as well as RTE 16 to 18, and 104, which are not handled neither. 3) Most DOS-specific errors are not handled at all (see RTE150 - 162). 4) RTE 202 (Stack check error), and RTE210 (object not initialized) are not handled. 5) RTE206 is translated to EOverflow, although there is an EUnderflow exception type. 6) RTE212 (stream registration error) is translated to an EExternal exception, although EExternal should probably not be raised on its own, but rather provide as base class for real external error situations. 7) RTE213 again is not handled, while RTE214 (collection overflow error) suddenly becomes an EBusError. 8) Why is RTE217 (unhandled exception) translated to EControlC? 9) RTE220 - 225 are not documented as Variant errors. For me it looks as if the runtime error to exception translation is more or less screwed anyway. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Are you sure this would make things easier? Code in the handler needs to be thread safe. Starting a thread is very easy, with TThread? If you use common resources of course you do need to take create to do it in a thread save way. But if you want to off-load some kind of work to one or more threads you need to do the communication - especially notifications between the threads - in a way everybody needs to invent for himself. Mostly you will (or even need to) use non-portable methods (Windows-Messages) for that. I always feel that it's not nice that when doing a thread you can't use event-driven programming (as everybody does in the main thread), but need to do your own work-loop per thread. (I do know that modifying this would be a _major_ RTL enhancement. So I'm not suggesting to start working on that right here. I'm just thinking about a means to integrate it into the language at a future point in time.) Some predefined, portable and easy to understand (i.e. very similar to main-thread programing) way to work with threads would be a nice enhancement over what any other Delphi-Language successor provides right now. Here I can imagine extending Events (including may those of the standard libraries provide) to working as threads could be a way to go. Or do you mean you want something like work queues? Supposedly some queuing mechanism needs to be used to provide parameters to the thread and to pass results back to the program that defined the event would be used. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel