Re: [fpc-devel] property syntax extension

2007-10-22 Thread Michael Schnell

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

2007-10-22 Thread Michael Schnell
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

2007-10-22 Thread Micha Nelissen

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

2007-10-22 Thread amir
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

2007-10-22 Thread Vinzent Hoefler
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

2007-10-22 Thread Michael Schnell




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