Re: Question about adding !function_identifier

I think the issue here is that there is no functional difference between an exclamation mark prefix and a docblock attribute, and the latter has the advantage of being more explicit, not requiring changes to the language syntax itself, and being an already-existing standard.  Of course things may move around during the development process, but I don't really see how you can't move around the docblocks with the functions they belong to... A decent IDE will make this easy and can also use the @throws tag to provide the contextual information you're looking for, again, without having to change the language itself. Best, Stijn Op 3 april 2019 bij 18:52:58, M. W. Moe (mo.mu.wss@gmail.com) schreef: Hello, not documenting at first is not really a question of laziness or so, as things are still moving around you absolutely need this agility; a good design layout between theory and stable state will refactored discussed a thousand times; that what I expect from engineers; filling the gaps between assumptions and reality. And for me-self throw vs no throw is important language information and part of internal behaviors; to clarify, for instance, would be more useful to have such indicator rather than having having abstract and interface which are cumbersome; same as the extra public keyword; you can do without especially with the new traits construct. Best. On Wed, Apr 3, 2019 at 9:42 AM Rowan Collins <rowan.collins@gmail.com> wrote: > On Wed, 3 Apr 2019 at 17:27, M. W. Moe <mo.mu.wss@gmail.com> wrote: > > > yes this is very true; but usually on complex design with a lot of folks > > working on it you start coding before documenting; > > > > > If it's just syntax that doesn't change behaviour, it's really just > documentation anyway, and if people are so desperate to dig into the code > that they can't write a minimal docblock (or so lazy that they won't), how > likely is it that they'll correctly add this new indicator? > > If you want to be explicit, don't put off docblocks until later (writing > them before you've even implemented the function can be a great way of > clarifying your design), and use an IDE or CI tool that will tell you when > they're missing or incorrect. > > Regards, > -- > Rowan Collins > [IMSoP] >