> On Sep 3, 2018, at 4:14 PM, Michael Van Canneyt <mich...@freepascal.org>
> wrote:
>
>>> On Sep 3, 2018, at 2:41 PM, Michael Van Canneyt <mich...@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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
