[fpc-pascal] with in classes/records

[Michael Van Canneyt]

On Mon, 3 Sep 2018, Ryan Joseph wrote:

>
>
>> On Sep 3, 2018, at 4:14 PM, Michael Van Canneyt <michael at freepascal.org> wrote:
>> 
>>>> 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 strongly feel that preventing thinking is an insult for any intelligent person.
>> 
>> We're not "input monkeys" after all.
>
> Fair enough.  :) I was kind of joking but seriously the name is redundant
> and doesn’t provide any meaning because the name isn’t actually used.

See below.

> The
> only reason we have the name is because we’re trying to add this feature
> on top of properties syntax.  Array properties had this oddity also and I
> would prefer to just omit the name since it’s meaningless.

It is not redundant. 
1. The compiler needs to know what field it maps to.
2. You need it to disambiguate.

Me = Class
   A : me;
end;

You = class
   f : Me;
   property a : me Read f write F;
end;

You need to be able to do

Var
   b : me;

You.a:=b;
you.a.a:=b,

You need the name or you will not be able to disambiguate between the 2 cases.



> Take the example of:
>
> property _delegateA: TSomeManager read delegateA write delegateA; default;
>
> What does naming it _delegateA add? the name is never used. Declaring the type and the read is also redundant. Just lots of typing.


>>> 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;
>> 
>> Obviously, only 1 default property should be allowed. Be it an array array or not.
>> 
>> Allowing multiple defaults will wreak havoc on precedence rules:
>> The order of property declarations would suddenly matter and that would of course be terribly wrong.
>> So that will certainly not be accepted.
>
> yeah, that’s the part I got pushback on before. Allow to make my case again. :)
>
> Precedence is already skewed by allowing default in the first place so why is it so dangerous to allow further (optional) levels of introspection? I think we could find ways to make this safe if we thought about it some more.

Precedence is not skewed by 'default' if there is only 1 'default'.

1. Check Object
2. Check 1 member of object.
That's it.

The same was true for array. It only works because there is only 1 default allowed.

So this is not negotiable as far as I am concerned.

and, so it seems, for other people of the team. 
I was unaware of that, but I agree with them.

>> it, it will most likely have many unwanted side effects.
>
> But why do we want to make this assignment? Now even I’m worried about ambiguous calls. ;) I guess because it’s a property we might as well do it because that is what properties allow but I feel like it’s being added just because we have to.

The whole point of 'default' is to be able to make this assignment, for example to implement nullable types.

As I said, your idea of 'with' is not exactly the same as 'default' on a simple property.
It shares some properties, but it is not the same.

Michael.