[fpc-devel] Re: [fpc-l] type discussion
Jamie McCracken
jamie-junk at blueyonder.co.uk
Sun Jun 5 14:05:37 CEST 2005
Daniël Mantione wrote:
>
> Op Sun, 5 Jun 2005, schreef Jamie McCracken:
>
>
>>Its not a black or white issue IMO its a shade of grey. At the end of
>>the day you have to make a judgement call based on the facts. Im
>>asserting that with non-component objects the incidence of cycles is so
>>rare that provided we have a means of adding weak refs so that
>>knowledgable developers can overcome them when they do occur then the
>>issue of cycles can be ignored - after all if the probability of leaks
>>is based on a one in a million occurance of a cycle (Im not saying thats
>>an accurate probability!) coupled with an ignorant or naive developer
>>then thats an acceptable risk to me. If it turns out that cyclic
>>occurances are far more common than that then yeah that could be a
>>killer. There are of course workarounds but I dont like any of them - EG
>>python 2.3 does ref counting but also uses a mark sweep GC to mop up
>>cicrular refs but I really dont think we need to consider that.
>
>
> Hmmmm... I don't think a programming language where one cannot safely
> build graphs or ringbuffers will be very powerfull. Writing a compiler in
> it would be impossible to give an example.
yes but isn't it fair to say that such developers that require such
structures would be knowledgable enough to make it safe by using weak refs?
My point is that the everyday structures that most developers (and in
particular the more naive and less knowledgable ones) will use are not
vulnerable to cycles and its only the more obscure and specialised use
cases that will need to use weak refs. In those cases like building a
compiler is it reasonable to assume that they will be smart enough to
handle cycles with weak refs?
jamie.
>
> Daniël
>
>
> _______________________________________________
> fpc-devel maillist - fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
>
More information about the fpc-devel
mailing list