[fpc-pascal] with in classes/records

[Ryan Joseph]

> 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. 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.

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.

Ideally all you really need in terms of information is this:

property delegateA; default;

I know it breaks property syntax but that’s all we really need.

Hope that makes sense. I just want to make for absolute certain using properties is the best approach.

> 
>> 
>> 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.

Here’s my delegation example using classes:

type
 TSomeManager = class
   procedure ManageThis;
   procedure DoThis;
 end;  

type
 TOtherManager = class
   procedure ManageThat;
   procedure DoThis;
 end;

type
 TMyClass = class
   delegateA: TSomeManager; with;	// I know, I just wrote it like this for brevity
   delegateB: TOtherManager; with;	// COMPILER ERROR (see below): TOtherManager has duplicate method ‘DoThis' from TSomeManager
 end;

var
  c: TMyClass;

c.Free;  // what does Free do here??? TMyClass, delegateA and delegateB are all TObject's!

I think you said properties come after the current class so Free would be called on TMyClass. Is that really that dangerous? Personally I’m inclined to see the benefit than the potential dangers but I understand how this could go wrong. The with statement has existed forever and it certainly can cause bugs. That’s just how programming is I guess.

What about giving errors if naming conflicts arise? I don’t even think class helpers do that but those were allowed. In fact this is very similar to class helpers isn’t it?

We can make this is as safe as helpers I’m quite certain. I just had this problem today and needed to breakup a class hierarchy using delegation and it would be 100% safe. I’ll make an example later.

> 
> ?? Default is not required at all. It's only required if you want to write
> A[i]
> instead of
> A.SomeProperty[i]

Ah, I should have guessed that. In my mind the sole reason to use array properties is so you so you can just do A[], never considered it otherwise.

>> Not sure what you mean exactly. Not sure how it would look on field.s
> 
> Same as on a property ?
> 
> A = Record
>  f : Tfield; Default;
> end;
> 
> I would not allow this.

agreed. Doesn’t make sense for what we’re after.

>> 
>> The context of the property “B” is “C” so “write" means assigning to “C” right? That obviously doesn’t make sense.
> 
> It depends on type compatibility.
> 
> if C and someA are assignment compatible types, then the above will just assign
> SomeA to C.
> 
> If C and someA are not assigment compatible types, then the compiler can
> look for a default property (not an array) which is assignment compatible
> with someA, and transform it to
> 
> C.FA:=SomeA;
> 
> You could decide to make this process recursive, but I would advise against
> 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.

I’d like to hear if others think this is a useful operation to do. Honestly I’m still skeptical as to why this is being built on top of properties in the first place given all the redundancies.

> 
>>>> 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.
> 
> No doubt - see above - but most of us are grown-up adults and can handle controversy in a civilized manner.

That’s all in good fun, I’m just encouraged that something I need is being considered even though I have a questionable ambition to make it work like a with statement. That much aside it’s still good news for me.

Regards,
	Ryan Joseph