[fpc-pascal] with in classes/records

[Ryan Joseph]

> On Sep 3, 2018, at 8:16 PM, Michael Van Canneyt <michael at freepascal.org> wrote:
> 
>> 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.

Sure I understand in that example but that doesn’t apply with the default property. The very purpose that the property is default is so we don’t need to refer to the name. Correct?

The reason I’m so confused about the proposal to make it a property is because the name itself is disregarded and that’s kind of the entire reason for properties, ie., to make another name which acts an alias. Once you take the name out by making it default it’s not really a property anymore.

In your example if the “a” property was default than:

You.Free;

would be the same as:

You.f.Free;

right? I just don’t see where the name of the property applies. The property *removed* a name in fact. It’s like an anti-name. ;)

Please correct me where I’m wrong.

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

But you can still have naming conflicts even with one level of indirection. Right? Class helpers and with statements both pose this same problem but we manage them for the benefits.

My logic is if we can do step #1 and step #2 then it follows that step #3 should be viable. It’s just an arbitrary restriction for some perceived level of safety and we lose functionality.

Did you not find my idea to give compiler errors compelling? I know we can make this safe and it’s a powerful feature for delegation patterns if the programmer can design the program properly.

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

Array is safe because there’s only one way [] can be interpreted.

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

My appeal is that we can make this safe and robust which will enable some really powerful delegation patterns that inheritance or class helpers can’t solve.

If I make a concrete example of a real world problem will that interest anyone? Maybe it’s not clear why this is useful and in leu of that I can understand why this sounds like a bad idea that will cause bugs.

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

Really? :) I thought it was for management operators so that they could pose as an alias for the wrapped type. The reason I reopened this “with” in classes is because it resembled the same aliasing idea that would allow delegation.

I guess this is a good time to ask, what are the other usage cases?

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

Indeed.



Regards,
	Ryan Joseph