[fpc-pascal] with in classes/records

[Ryan Joseph]

> On Sep 3, 2018, at 2:41 PM, Michael Van Canneyt <michael at freepascal.org> wrote:
> 
> 'with' is terribly awkward.

“with” came to mind because it’s basically a with statement but within a class. Properties had another side effect of requiring naming which is redundant (I’d probably just underscore the name always by default to prevent thinking). 

I just learned about the management operator issue recently but my initial interest was for any number of properties to be added and thus “default” didn’t make lots of sense in my mind.

Properties also didn’t make sense to me because they’re always “read", i.e. “write" doesn’t make sense given the context (write would always be an ambiguous statement). 

Doesn’t that look kind of redundant? The plus side is at least they get to hook into the property symbol class.

type
 TMyRec = record
   delegateA: TSomeManager;
   delegateB: TOtherManager;

   property _delegateA: T read delegateA; default;
   property _delegateB: T read delegateB; default;
 end;

> 
> If it needs to be done, please use 'default', it is in line with the default array property.

In my first tests I found that indeed “default" was used for array properties and the modifier “default” was kind of tangled up for arrays. What is the thinking behind “default” for array properties anyways? I always add it because the compiler requires it but there’s probably more to it than that.

So yeah, the default keyword appeared to be reserved for arrays in the code so I wanted to make sure that’s really the correct approach.

> 
> I suggest you only allow it on properties, not on fields. In the case of records, this will automatically imply the use of advanced records, and would prohibit it on classical records.

Not sure what you mean exactly. Not sure how it would look on field.s

> 
> Make sure you establish precedence rules correctly. The default should only be
> searched after all other properties/fields were handled.
> 
> TA = Class
>  B : Integer;
> end;
> 
> TB = record
> Private
>  FA : TA;
> Public
>  Property A : TA Read FA Write FA; default;
>  B : Integer;
> end;
> 
> Var
>  C : TB;
> 
> begin
>  C.B // Must refer to TB.B, not C.A.B
> end.
> 
> I'm sure there are other pitfalls.

You’re right, no doubt about pitfalls depending on how it works.

In my first naive test I just did some extra searches in searchsym_in_record and added a csubscriptnode node if a match was found. That works for records but I didn’t try to make generics work. Because this only works with classes/records I think it only makes sense for the property to be “read” right? All it does it basically takes:

C.B := 100

and expands it to 

C.FA.B := 100

by adding the “FA” subscript node

if the property was write it would imply:

C := someA;

The context of the property “B” is “C” so “write" means assigning to “C” right? That obviously doesn’t make sense.

> 
>> 2) If there is any plausible way the compiler team will allow this I’m
>> willing to develop it myself to what every specification the team decides. I already looked into how this could be implemented and did some tests. It’s not complicated and within the range of something I could accomplish.
> 
> Patches are always plausible.
> 
> Just dive in and ask questions. Help will surely be provided. When you feel you're done, provide a patch. It will be considered like all
> other patches.

Great news! I think there’s still some controversy ahead though about how to implement this.

Regards,
	Ryan Joseph