[GSOC] regular expressions beta is here

[Dmitry Olshansky]

On 10.08.2011 21:11, bearophile wrote:
> Dmitry Olshansky:
>
>> Honestly I can't get why you are so nervous about code style anyway, you
>> seem to bring this up way to often.
> I bring it often because many D programmers seem half blind to this problem. I am not willing to go to the extremes Go language goes to solve this problem, but I'd like more recognition of this problem in D programmers. A bit more common style is quite helpful to create an ecology of D programmers that share single modules. I guess D programmers are used to C/C++ languages, where there are not modules and where programs are usually made of many files. So they don't see why sharing single modules in the pool is so useful.
>
>
>> About spaces personally I dislike eating extra vertical space for
>> "clarity", curly braces on it's own line is already way too much.
> Think about reading a book without the half lines between paragraphs. In code it's the same. Some empty lines are good to improve readability of the code. Curly braces are not always present, sometimes a paragraphs ends before or after or right on a curly brace.

Braces *are* paragraphs of code, with proper indention it's more then 
enough to fell the structure. If I really need to stop in the middle 
function, it's to explain something, then a single line of comment 
instead of meaningless empty line (which leaves reader clueless as to 
why) is good enough. Except that I'm not opposed to spaces at global scope.

>
>> Have to respectfully disagree on this, don't try to nail everything on
>> contracts.
> Contracts don't replace unittests, they complement each other.
>
unittest != assert, though the former do contain asserts.
>> They are nice but have little value over plain assert
>> _unless_ we are talking about classes and _inheritance_, which isn't the
>> case here.
> It's easy to forget to test the output of a function, the "out" contracts help here. In structs the invariant helps you avoid forgetting to call manually a sanity test function every time you come in and out of a method.
>
>
>> And there are lots of asserts here, but much more of input is
>> enforced since it's totally expected to supply wrong pattern (or have an
>> outside  user to type in the pattern).
> The idea is to replace those enforces with asserts, and allow user programs to import Phobos stuff that still contain asserts (from a secondary Phobos lib). Enforces are for certain kinds of user code, I don't think they are fit in Phobos.
>
>
No gonna work, file I/O is certainly in Phobos, as are network sockets, 
etc. You can't assert that something external won't fail. While you'd 
normally assert on your local logical invariants. As for other things I 
thought e.g. ranges are already hooked on asserts, as much as other 
templates. If you have a list of modules where you find the lack of 
compiled in contracts/asserts unbearable, do tell.

I hate being drugged in these discussions, but just can't resist.

-- 
Dmitry Olshansky