Re: [fpc-devel] (ref types / circles) Re: Defer keyword
> On May 10, 2021, at 3:18 PM, Ryan Joseph wrote: > > Lets focus on the record approach for now then. I don't think I know enough > to understand where are the pitfalls are. This was another thing I wanted off my mind since a couple years ago already so I got a pretty good start of an implementation. Since Sven has made it pretty clear we can't add ARC to Pascal without altering all instances of TObject, this is the next best thing. Together with record management operators this is how we can achieve "smart pointers" in Pascal. I've constrained the implementation to hoisting the following members: * Fields (duplicate field names with the record gives errors) * Properties (last-wins, like in class hierarchies) * Methods (and overloading with the method itself) * for..in enumerator so container classes can be used naturally (other operators are not supported to keep the implementation simple for 99% use cases) * Hoisting happens only by subscripting from the outside, so not within the record using implicit-self. * Only records + classes are supported types (in the interest of keep the feature for ARC and not other things like nullable types or traits/mix-ins etc...) https://bugs.freepascal.org/view.php?id=38872 Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
Am 15.05.2021 um 20:08 schrieb Ryan Joseph via fpc-devel: On May 15, 2021, at 10:49 AM, Ryan Joseph wrote: Also it looks like ChangeOwnerAndName isn't making the compiler happy. Sorry for the noise, I figured out it was because the name had spaces. How should I make the name then? I'm doing this for now which is certainly unique but it's not standard. newtype:=ctypesym.create(def.fullownerhierarchyname(false)+typName[def.typ]+'$'+def.unique_id_str,def); It will make names like below which don't upset the assembler. SOMETESTUNIT.arraydef$5 Anyways, I put up a patch on the bug tracker (https://bugs.freepascal.org/view.php?id=35261) for you to review and see if I did this right. I had already wondered why that worked previously. But yes, that approach is better. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
Am 15.05.2021 um 18:27 schrieb Ryan Joseph via fpc-devel: On May 13, 2021, at 2:38 PM, Sven Barth wrote: Ah, you need to use ChangeOwnerAndName then and simply pass in the same name you used for the constructor (cause otherwise it tries to use the name that is currently stored in the list). Looking at this again today and I have yet another question to confirm. I create one of the types using ctypesym.create but the others were just references from the system unit. We only want to change owner of the symbol I create, right? Not the system unit ones? If not changing owner maybe we need to add some ref count or something? just confirming to make sure. You only need to change the owner of those you create using ctypesym.create. The others are preexisting and you must not touch them in any way. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
