[fpc-pascal] Optional param modifier
Martin Frb
lazarus at mfriebe.de
Sat Apr 13 21:58:19 CEST 2019
On 13/04/2019 21:07, Ryan Joseph wrote:
>
>> Already today the author could add a comment (even pasdoc) to the declaration. And it serves the same effect.
> Sure, if it’s not used then it’s not very helpful. :) Comments are the same effect? Then why not prefer comments for “const” params or even public/private sections. Surely this isn’t a good idea:
You misread me. I am sure inadvertently, but still. You advertised that
this feature you desire was to fulfil two purposes. One of which you
named to be documentation. Or as you described, the elimination of the
need to look through copious amounts of implementation, or in other
cases pages of documentation.
As for this part of your request, I made it known that it is my belief
that comments can have the same effect.
As for the second purpose that you had brought to our attention, I gave
answer to it further down in my mail.
>> Also the is a difference between:
>> - the parameter is nil-able (better term that optional, optional has a different meaning)
>> - the compiler needs to enforce an check for "<> nil"
>>
>> If the parameter is only stored, for later usage, then the nil can be stored too. There is no check needed for that.
>> It will be needed later in some other function, but the compiler can not know where that may be.
>>
>> You can even call methods on an object that is nil. So long as they are:
>> - not virtual, nor call virtual methods themself
>> - do not access "self" without prior check that it is not nil
> All true. I only propose this for cases where nil could be passed/returned and the programmer can be given more information and forced to check since this is the pattern they were supposed to do anyways. It’s not a magic catch-all, just a minor markup thing like “const” is.
Well, as far as the "optional" part goes, the benefits of it will be
fairly limited. Object variables occur in many places, and all of them
can have the nil value, and the compiler has no idea if you did the check.
You pick a tiny subset of those cases, and attempt to add protection to
it. Given the gain (or rather absence of it, according to the
microscopic size of that subset) the effort (and chance of false
positives) is not worth it.
I have already in todays code encountered the compiler telling me
variables were not initialized, were clearly they were. But the compiler
was not smart enough to follow the code through various conditional blocks.
If the compiler were to force that check, when at the same time it is
not smart enough to see, that I actually already have it, then clearly
that would be a problem.
Besides there is a "loop"hole (pun intended / follows) in this feature.
The feature creates a circular (loop) dependency.
If I want the compiler to force me to add the check, I need to add the
keyword. But if I remember to add the keyword, well I may as well add
the check instead. After all I am already aware of its need, or I would
not add the keyword.
So if I am not aware of the need for the check, I am likely not to add
the keyword, and I will never know (until my app crashes)
More information about the fpc-pascal
mailing list