Re: Usability of latest DMD 1.x
All releases are sent to Lars before going out so the Tango team can let me know if I broke something. I haven't heard any word that it has.
Re: reddit.com: first Chapter of TDPL available for free
Daniel Keep wrote: Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/ (Don't tell anyone, but I plan to rewrite it.) Andrei Dump of thoughts as I read it: Awesome! Recorded. Hey I thought you gave up on D ;o). Thanks mate, Andrei
Re: Usability of latest DMD 1.x
"Bill Baxter" wrote in message news:mailman.291.1249531861.14071.digitalmar...@puremagic.com... >I just tried to upgrade my DMD from 1.041 to 1.046 and things aren't > working so well. > I see Tango is still based off 1.041 too. So have the releases since > then all had problems? Or are these two facts just a coincidence? > 1.43 works with Tango 0.99.8, but 1.44 introduced a breaking change that required a change in tango (which I've been told is in tango trunk). So 1.44+ requires Tango trunk, at least until 0.99.9.
Usability of latest DMD 1.x
I just tried to upgrade my DMD from 1.041 to 1.046 and things aren't working so well. I see Tango is still based off 1.041 too. So have the releases since then all had problems? Or are these two facts just a coincidence? --bb
Re: Searching the digitalmars.com/d website
Adam D. Ruppe wrote: > On Thu, Aug 06, 2009 at 01:15:10PM +1000, Daniel Keep wrote: >> Your Google-fu is weak, grasshopper. > > I added that to my fledgling D tips page: > > http://arsdnet.net/dtips/ > > You don't mind the quotation there do you? (just checking for copyright > purposes) > > > This is the kind of little tip that would be hugely beneficial to people; > I often found myself wondering how to do that too. > > Thanks! I don't think you could realistically expect to copyright something that short, but just in case: go for it.
Re: Naming things in Phobos - std.algorithm and writefln
Benji Smith wrote: > ... > > The thing about one-letter abbreviations is that they mean different > things in different contexts. An "f" might mean "formatted" in a > "writefln" function, but it means "file" in an "ifstream" and "floating > point" in the "fenv" module. I don't think this applies. Firstly, I was talking about suffixes, not abbreviations appearing in other parts of a name. Secondly, the convention is: "an f suffix on an output method means formatting." That doesn't conflict with fenv at all since the f there isn't a suffix and "env" has nothing to do with output at all. Besides, even if you thought the "f" was "formatter", you'd be quickly dissuaded when you looked in the docs and saw "fenv.h is the standard header providing access to the floating point environment." The ambiguous case is ifstream which could be interpreted as "input formatted stream" if you were really trying. But here's the kicker: "ifstream" is a bad class name ANYWAY because it's all lowercase and highly ambiguous. A sane name for ifstream would be FileInput which drops the redundant "stream", expands both the "i" and "f" to their full names and is only one character longer. Win! Finally, I don't think you can just toss context out the window completely and say 'but there's an f; it could mean anything!'. No, interpret it based on context and all will be well. If you have an output function on a file with an 'f' suffix, odds are it means "format". If you have a logging function on a logging object with an 'f' suffix, odds are it means "format". If you have an inverse square root function on a math object with an 'f' suffix, odds are it really doesn't mean "format". Given we have overloading, my guess would be "fast", and then I'd check the docs. > In those cases (and in many more), there's no convention than can be > reused. You just have to memorize stuff. Memorization was a perfectly > acceptable solution back in the days of C, when standard libraries were > small. But I think any modern standard library, with scores of modules > and hundreds (or thousands) of functions, needs a better strategy. You can't not memorise stuff. You have to look up the docs if you don't remember what a function's arguments are or what its semantics are irrespective of the name. > Coming from a Java background, I much prefer to give up terseness in > favor of clarity. Though I recognize that verbosity has its own > pitfalls, I think it's the lesser evil. > > --benji It's alright; enough electro-therapy will cure you of your Java tendencies. We CAN save you!
Re: Searching the digitalmars.com/d website
On Thu, Aug 06, 2009 at 01:15:10PM +1000, Daniel Keep wrote: > Your Google-fu is weak, grasshopper. I added that to my fledgling D tips page: http://arsdnet.net/dtips/ You don't mind the quotation there do you? (just checking for copyright purposes) This is the kind of little tip that would be hugely beneficial to people; I often found myself wondering how to do that too. Thanks! -- Adam D. Ruppe http://arsdnet.net
Re: Searching the digitalmars.com/d website
Chad J wrote: > Walter Bright wrote: >> Ary Borenszweig wrote: >>> Strange: now my previous searches work (well, most of them). What >>> could have happened? >> Sometimes google gives erratic behavior if part of their farm goes down. > > Any chance we can get a search that /only/ searches the spec? > > Not only is such a thing long overdue, but it would allow us to > circumvent such erratic behavior to a degree. Your Google-fu is weak, grasshopper. To search for "pure functions" only within the spec and standard library: pure functions site:digitalmars.com inurl:/d/2 Note that this includes the various articles as well. If you want to exclude Phobos, drop a -inurl:/phobos/ on the end.
Re: Searching the digitalmars.com/d website
Walter Bright wrote: > Ary Borenszweig wrote: >> Strange: now my previous searches work (well, most of them). What >> could have happened? > > Sometimes google gives erratic behavior if part of their farm goes down. Any chance we can get a search that /only/ searches the spec? Not only is such a thing long overdue, but it would allow us to circumvent such erratic behavior to a degree.
Re: DIP6: Attributes
Jacob Carlborg wrote:
On 8/4/09 18:55, Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 09:45:51 -0400, grauzone wrote:
Steven Schveighoffer wrote:
don't think it's worth adding them until we can have full
reflection capabilities so we can get at elements of code and
therefore get the annotations associated with it. I see much more
usefulness for annotations as reflection hints than as a
replacement for keywords.
But we already have full reflection. It's called __traits. You can
build a serialization library or "proper" (user friendly?)
reflection on top of it.
I think you are the 1 millionth person to say it, and yet we still do
not have a "user friendly" reflection system. Why is that? You'd
think that if it could be done, somebody would have done it by now.
The reality is there's quite few of us. D is not in the stage where if
something could be done, somebody somewhere has done it or is working
on it.
That's understandable, nobody can expect a language as young as D to
have everything.
But in reality, I think the *theory* that everything is there to build a
reflection system is only proven when it actually happens. I'm sure when
the enterprising person or persons go to develop it, they will find
pieces missing from the static reflection system.
So my point is that adding annotations before reflection works and is
implemented makes little sense to me, because the usage of them will be
crippled by the fact that reflection isn't complete.
What I'd like to see is something like this possible:
void foo (int timeout, string bar, float f = 4.0);
void foo(int timeout);
call!(foo)("timeout=5,bar=\"hello\"");
Taking into account the default value of f, what the parameters are
named, and which overload to call. I could certainly do it with C#.
-Steve
You mean like this: http://tango.pastebin.com/m129241b0 ?
/Jacob Carlborg
static assert(jacobCarlbord.ninjaLevel == BlackBelt);
Re: Naming things in Phobos - std.algorithm and writefln
Daniel Keep wrote: That way, if someone writes logging functions one day that takes formatted strings in the same way, he can reuse the convention: log logLine logFormat logLineFormat instead of "log", "logln", "logf", and "logfln". If you create a hash function, you can reuse the pattern too: hash hashLine hashFormat hashLineFormat instead of "hash", "hashln", "hashf" and "hashfln". And it goes on. How is this an improvement? If we accept that people know what the "f" and "ln" suffixes mean (and given that they will be exposed to this in the course of writing a Hello, World! program), what benefit is gained from increasing the length and complexity of the identifiers? Saying you can re-use the convention is irrelevant because the exact same thing can be said of the shorter suffixes. The thing about one-letter abbreviations is that they mean different things in different contexts. An "f" might mean "formatted" in a "writefln" function, but it means "file" in an "ifstream" and "floating point" in the "fenv" module. In those cases (and in many more), there's no convention than can be reused. You just have to memorize stuff. Memorization was a perfectly acceptable solution back in the days of C, when standard libraries were small. But I think any modern standard library, with scores of modules and hundreds (or thousands) of functions, needs a better strategy. Coming from a Java background, I much prefer to give up terseness in favor of clarity. Though I recognize that verbosity has its own pitfalls, I think it's the lesser evil. --benji
Re: Naming things in Phobos - std.algorithm and writefln
On 2009-08-05 20:08:43 -0400, Andrei Alexandrescu said: But then I thought D2 was about making things better without worrying too much about backward compatibility. I find it dubious that we are ready to do a breaking language change about how properties work, but when it comes to replacing some standard library functions we can't because of backward compatibility. What is the criterion for an acceptable breaking changes? That's what I keep on telling Walter! That, and the fact that American cars suck! You mean it's Walter who don't want to break this kind of compatibilty? In any case, if Walter can fix alias this so that we can really do implicit casts, it will become possible to return a lazy range that implicitly convert to an array when needed. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Naming things in Phobos - std.algorithm and writefln
On 2009-08-05 19:16:17 -0400, Jarrett Billingsley
said:
On Wed, Aug 5, 2009 at 7:00 PM, Michel Fortin wr
ote:
Also, with implicit casts we wouldn't even need to bother about having a
different names for lazy and non-lazy results, we could just do:
string[] parts = str.split();
and it would implicitly convert the lazy range to an array. Can this be d
one
with alias this? Would need to test.
struct Range(T)
{
T[] toArray();
alias toArray this;
... other range things here...
}
Sadly it doesn't work. I was hopeful when I found this works:
struct X { int x; alias x this; }
auto x = X(5);
int y = x; // works!
but if you alias a method that returns int to 'this', that line fails.
Looks pretty much like this bug. Put your vote on it.
There's also such an example in the original enhancement proposal for
alias this from Andrei.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Naming things in Phobos - std.algorithm and writefln
Michel Fortin wrote: On 2009-08-05 17:40:34 -0400, Andrei Alexandrescu said: Sergey Gromov wrote: Wed, 05 Aug 2009 17:29:11 +1000, Daniel Keep wrote: Michel Fortin wrote: In std.algorithm, wouldn't it be clearer if "splitter" was called "splitLazily" or "splitLazy"? "splitter" is a noun, but as a function shouldn't it be a verb. "makeSplitter" or "toSplitter" perhaps? This is a specious argument. splitter's only purpose is to return an instance of a Splitter struct. You can't call it "splitLazily" or "splitLazy" because that implies that the function is doing work, when it really isn't. That's if you know how it works. But if you just use these functions, it's not even remotely obvious what the difference is, and the difference in naming is so subtle that many people will be doomed to forever confuse these functions, myself included. I confuse getopt and getopts shell functions in the same way. I simply can't remember which is which. Very true. If it weren't for backwards compatibility, I'd simply have split() do the lazy thing. Then array(split()) would do the eager thing. But then I thought D2 was about making things better without worrying too much about backward compatibility. I find it dubious that we are ready to do a breaking language change about how properties work, but when it comes to replacing some standard library functions we can't because of backward compatibility. What is the criterion for an acceptable breaking changes? That's what I keep on telling Walter! That, and the fact that American cars suck! Andrei
Re: Naming things in Phobos - std.algorithm and writefln
On Wed, 05 Aug 2009 18:47:35 -0400, Michel Fortin wrote: On 2009-08-05 17:40:34 -0400, Andrei Alexandrescu said: Sergey Gromov wrote: Wed, 05 Aug 2009 17:29:11 +1000, Daniel Keep wrote: Michel Fortin wrote: In std.algorithm, wouldn't it be clearer if "splitter" was called "splitLazily" or "splitLazy"? "splitter" is a noun, but as a function shouldn't it be a verb. "makeSplitter" or "toSplitter" perhaps? This is a specious argument. splitter's only purpose is to return an instance of a Splitter struct. You can't call it "splitLazily" or "splitLazy" because that implies that the function is doing work, when it really isn't. That's if you know how it works. But if you just use these functions, it's not even remotely obvious what the difference is, and the difference in naming is so subtle that many people will be doomed to forever confuse these functions, myself included. I confuse getopt and getopts shell functions in the same way. I simply can't remember which is which. Very true. If it weren't for backwards compatibility, I'd simply have split() do the lazy thing. Then array(split()) would do the eager thing. But then I thought D2 was about making things better without worrying too much about backward compatibility. I find it dubious that we are ready to do a breaking language change about how properties work, but when it comes to replacing some standard library functions we can't because of backward compatibility. What is the criterion for an acceptable breaking changes? About 500 more posts ;) -Steve
Re: Naming things in Phobos - std.algorithm and writefln
On Wed, Aug 5, 2009 at 7:00 PM, Michel Fortin wrote:
> Also, with implicit casts we wouldn't even need to bother about having a
> different names for lazy and non-lazy results, we could just do:
>
> string[] parts = str.split();
>
> and it would implicitly convert the lazy range to an array. Can this be done
> with alias this? Would need to test.
>
> struct Range(T)
> {
> T[] toArray();
> alias toArray this;
>
> ... other range things here...
> }
Sadly it doesn't work. I was hopeful when I found this works:
struct X { int x; alias x this; }
auto x = X(5);
int y = x; // works!
but if you alias a method that returns int to 'this', that line fails.
Re: Naming things in Phobos - std.algorithm and writefln
On 2009-08-05 18:12:16 -0400, Bill Baxter said:
On Wed, Aug 5, 2009 at 2:40 PM, Andrei
Alexandrescu wrote:
Sergey Gromov wrote:
Wed, 05 Aug 2009 17:29:11 +1000, Daniel Keep wrote:
Michel Fortin wrote:
In std.algorithm, wouldn't it be clearer if "splitter" was called
"splitLazily" or "splitLazy"? "splitter" is a noun, but as a function
shouldn't it be a verb. "makeSplitter" or "toSplitter" perhaps?
This is a specious argument.
splitter's only purpose is to return an instance of a Splitter struct.
You can't call it "splitLazily" or "splitLazy" because that implies tha
t
the function is doing work, when it really isn't.
That's if you know how it works.
But if you just use these functions, it's not even remotely obvious what
the difference is, and the difference in naming is so subtle that many
people will be doomed to forever confuse these functions, myself
included. I confuse getopt and getopts shell functions in the same wa
y.
I simply can't remember which is which.
Very true. If it weren't for backwards compatibility, I'd simply have
split() do the lazy thing. Then array(split()) would do the eager thing.
Andrei
Maybe introduce a convention like python and bearophile? "foo" for
eager things and "xfoo" for lazy things is what they use. At least
when you first see xfoo, you don't automatically assume you know what
that "x" means, and go look it up if you don't know.
One question to ask is which one should be the default. If lazy should
be the default then we want the lazy on to be called "split" and the
non-lazy one to be called "eagerSplit" or whatever other convention for
non-lazy. "str.eagerSplit()" would just be a shortcut for
"str.split().toArray()".
Also, with implicit casts we wouldn't even need to bother about having
a different names for lazy and non-lazy results, we could just do:
string[] parts = str.split();
and it would implicitly convert the lazy range to an array. Can this be
done with alias this? Would need to test.
struct Range(T)
{
T[] toArray();
alias toArray this;
... other range things here...
}
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Naming things in Phobos - std.algorithm and writefln
On 2009-08-05 17:40:34 -0400, Andrei Alexandrescu said: Sergey Gromov wrote: Wed, 05 Aug 2009 17:29:11 +1000, Daniel Keep wrote: Michel Fortin wrote: In std.algorithm, wouldn't it be clearer if "splitter" was called "splitLazily" or "splitLazy"? "splitter" is a noun, but as a function shouldn't it be a verb. "makeSplitter" or "toSplitter" perhaps? This is a specious argument. splitter's only purpose is to return an instance of a Splitter struct. You can't call it "splitLazily" or "splitLazy" because that implies that the function is doing work, when it really isn't. That's if you know how it works. But if you just use these functions, it's not even remotely obvious what the difference is, and the difference in naming is so subtle that many people will be doomed to forever confuse these functions, myself included. I confuse getopt and getopts shell functions in the same way. I simply can't remember which is which. Very true. If it weren't for backwards compatibility, I'd simply have split() do the lazy thing. Then array(split()) would do the eager thing. But then I thought D2 was about making things better without worrying too much about backward compatibility. I find it dubious that we are ready to do a breaking language change about how properties work, but when it comes to replacing some standard library functions we can't because of backward compatibility. What is the criterion for an acceptable breaking changes? -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Naming things in Phobos - std.algorithm and writefln
On Wed, Aug 5, 2009 at 2:40 PM, Andrei Alexandrescu wrote: > Sergey Gromov wrote: >> >> Wed, 05 Aug 2009 17:29:11 +1000, Daniel Keep wrote: >> >>> Michel Fortin wrote: In std.algorithm, wouldn't it be clearer if "splitter" was called "splitLazily" or "splitLazy"? "splitter" is a noun, but as a function shouldn't it be a verb. "makeSplitter" or "toSplitter" perhaps? >>> >>> This is a specious argument. >>> >>> splitter's only purpose is to return an instance of a Splitter struct. >>> You can't call it "splitLazily" or "splitLazy" because that implies that >>> the function is doing work, when it really isn't. >> >> That's if you know how it works. >> >> But if you just use these functions, it's not even remotely obvious what >> the difference is, and the difference in naming is so subtle that many >> people will be doomed to forever confuse these functions, myself >> included. I confuse getopt and getopts shell functions in the same way. >> I simply can't remember which is which. > > Very true. If it weren't for backwards compatibility, I'd simply have > split() do the lazy thing. Then array(split()) would do the eager thing. > > Andrei > Maybe introduce a convention like python and bearophile? "foo" for eager things and "xfoo" for lazy things is what they use. At least when you first see xfoo, you don't automatically assume you know what that "x" means, and go look it up if you don't know. --bb
Re: Searching the digitalmars.com/d website
Ary Borenszweig wrote: Strange: now my previous searches work (well, most of them). What could have happened? Sometimes google gives erratic behavior if part of their farm goes down.
Re: Searching the digitalmars.com/d website
Walter Bright escribió: Tim Matthews wrote: You will probably find that when you have the correctly constructed query google is also easier to find things on the news groups. I also find google the easiest way to find anything on any site so I just use google otherwise I would be very busy reporting bugs / suggestions to every site I have ever searched. Google is the one doing the searching on the local search box, so I have no idea what the problem is caused by. Strange: now my previous searches work (well, most of them). What could have happened?
Re: Naming things in Phobos - std.algorithm and writefln
Sergey Gromov wrote: Wed, 05 Aug 2009 17:29:11 +1000, Daniel Keep wrote: Michel Fortin wrote: In std.algorithm, wouldn't it be clearer if "splitter" was called "splitLazily" or "splitLazy"? "splitter" is a noun, but as a function shouldn't it be a verb. "makeSplitter" or "toSplitter" perhaps? This is a specious argument. splitter's only purpose is to return an instance of a Splitter struct. You can't call it "splitLazily" or "splitLazy" because that implies that the function is doing work, when it really isn't. That's if you know how it works. But if you just use these functions, it's not even remotely obvious what the difference is, and the difference in naming is so subtle that many people will be doomed to forever confuse these functions, myself included. I confuse getopt and getopts shell functions in the same way. I simply can't remember which is which. Very true. If it weren't for backwards compatibility, I'd simply have split() do the lazy thing. Then array(split()) would do the eager thing. Andrei
Re: Naming things in Phobos - std.algorithm and writefln
Wed, 05 Aug 2009 17:29:11 +1000, Daniel Keep wrote: > Michel Fortin wrote: >> In std.algorithm, wouldn't it be clearer if "splitter" was called >> "splitLazily" or "splitLazy"? "splitter" is a noun, but as a function >> shouldn't it be a verb. "makeSplitter" or "toSplitter" perhaps? > > This is a specious argument. > > splitter's only purpose is to return an instance of a Splitter struct. > You can't call it "splitLazily" or "splitLazy" because that implies that > the function is doing work, when it really isn't. That's if you know how it works. But if you just use these functions, it's not even remotely obvious what the difference is, and the difference in naming is so subtle that many people will be doomed to forever confuse these functions, myself included. I confuse getopt and getopts shell functions in the same way. I simply can't remember which is which.
Re: Searching the digitalmars.com/d website
Tim Matthews wrote: You will probably find that when you have the correctly constructed query google is also easier to find things on the news groups. I also find google the easiest way to find anything on any site so I just use google otherwise I would be very busy reporting bugs / suggestions to every site I have ever searched. Google is the one doing the searching on the local search box, so I have no idea what the problem is caused by.
Re: scope, inline, optimizations, scoped attributes
Brad Roberts: >Stop there.< Nope, I don't stop there. That post was about another topic. Bye, bearophile
Re: scope, inline, optimizations, scoped attributes
On Wed, 5 Aug 2009, bearophile wrote: > But D contains "scope" to suggest the compiler to stack allocate a class > instance. Stop there. Scope doesn't mean stack allocate. Scope means controlled lifetime. The use of stack versus heap is an implementation detail and an optimization. Not that it's not a useful optimization, but that's secondary to the semantics of lifetime. Later, Brad
Re: scope, inline, optimizations, scoped attributes
On Wed, Aug 5, 2009 at 7:06 AM, bearophile wrote: > (Walter once said that D is slower than C++: it's often no longer true if you > use > LDC and if the code is the "same" (same = after compiler optimizations)). As far as I've seen Walter has always said D is as fast as C++ as long as you compare two compilers with equivalent optimizers (like DMD and DMC). --bb
Re: Naming things in Phobos - std.algorithm and writefln
Jeremie Pelletier wrote: Andrei Alexandrescu Wrote: Michel Fortin wrote: Alternatively, "writefln" could be an exception to the rules, but then the exception would need a better rationale than "it shouldn't look like Java". I mean, if Phobos makes unjustified exceptions to its naming conventions here and there for no good other reason than "it looks good", it breaks the concistency and makes function names less predictable and less readable. I agree that Phobos' names could use a good overhaul. That would make it easier for growing it too. Certain names could be kept short and intuitive although they don't fit common conventions. Andrei You could also use aliases to make everyone happy, thats what I do in my local phobos source, its just a bitch to upgrade to the newest dmd while keeping my own changes ;) One of the most annoying names I've had in phobos was the std.utf.encode/decode functions. When I would come across these in some code it wasnt descriptive enough as to what was being done. So I rewrote the std.utf module to use names such as toUTF8, toUTF16 and toUnicode, and made a generic toUTF template to call the proper one. Then aliased encode and decode to their corresponding toUTF calls to keep compatibility with the rest of phobos, works like a charm. I can mail you my version of std.utf if you want Andrei. I'd be glad to look at it! Just give me time. Andrei
Re: Iterators Must Go video online
Tim Matthews wrote: On Mon, 03 Aug 2009 12:47:40 -0500 Andrei Alexandrescu wrote: A while ago I mentioned the video of my BoostCon keynote "Iterators Must Go" will be soon available online. Here it is: http://boostcon.blip.tv/ Andrei I may have been mistaken but I thought I heard you say you re wrote the iterators as ranges twice. Once for D's std.range and once for C++ STL but I heard you then saying someone should re write STL. Do you have a re write of STL on the net anywhere? I wrote D's algorithms twice: once with iterators, once with ranges. Andrei
Re: Naming things in Phobos - std.algorithm and writefln
Andrei Alexandrescu Wrote: > Michel Fortin wrote: > > Alternatively, "writefln" could be an exception to the rules, but then > > the exception would need a better rationale than "it shouldn't look like > > Java". I mean, if Phobos makes unjustified exceptions to its naming > > conventions here and there for no good other reason than "it looks > > good", it breaks the concistency and makes function names less > > predictable and less readable. > > I agree that Phobos' names could use a good overhaul. That would make it > easier for growing it too. > > Certain names could be kept short and intuitive although they don't fit > common conventions. > > > Andrei You could also use aliases to make everyone happy, thats what I do in my local phobos source, its just a bitch to upgrade to the newest dmd while keeping my own changes ;) One of the most annoying names I've had in phobos was the std.utf.encode/decode functions. When I would come across these in some code it wasnt descriptive enough as to what was being done. So I rewrote the std.utf module to use names such as toUTF8, toUTF16 and toUnicode, and made a generic toUTF template to call the proper one. Then aliased encode and decode to their corresponding toUTF calls to keep compatibility with the rest of phobos, works like a charm. I can mail you my version of std.utf if you want Andrei.
Re: Naming things in Phobos - std.algorithm and writefln
Michel Fortin wrote:
I'm tring to see how I can adapt the guidelines to accept this function
("writefln") and I can't see any sensible rule I could add. Any idea?
Alternatively, "writefln" could be an exception to the rules, but then
the exception would need a better rationale than "it shouldn't look like
Java".
Um, how about "writefln is AWESOME" for a reason? :)
But seriously, I use writefln ALL the time. I can't find the words to
describe how much nicer it is than Tango's Stdout.formatln("blah") or
Java's System.out.println("aargh").
-Lars
Re: Searching the digitalmars.com/d website
On Wed, 05 Aug 2009 08:39:27 -0300 Ary Borenszweig wrote: > Sorry for brining this topic again, but there's something that really > worries me (not that I cannot sleep at night, but...) > > Take this page: > > http://www.digitalmars.com/d/2.0/function.html > > There are some big headers there: "pure functions", "nothrow > functions", "ref functions", "virtual functions", "Function > Inheritance and Overriding", "Function Overloading", etc. > > Searching *any* of those phrases (without the quotes) leads to > results other than that page. Searching them with quotes further > restrict the results, sometimes resulting in none. > > Maybe that specific page is not being indexed by that search box. But > it doesn't seem to be the case. I tried other random searches over > other page headers: > > - "Linkage Attribute" in > http://www.digitalmars.com/d/2.0/attribute.html: not what I was > looking for. > - "Properties for Floating Point Types" in > http://www.digitalmars.com/d/2.0/property.html: not what I was > looking for. > - "Class Properties" in http://www.digitalmars.com/d/2.0/class.html: > not what I was looking for. > - getVirtualFunctions in > http://www.digitalmars.com/d/2.0/traits.html: found it. > - "Order Of Evaluation" in > http://www.digitalmars.com/d/2.0/expression.html: no... > > I'm starting to think that some pages aren't being indexed. For > example in http://www.digitalmars.com/d/2.0/expression.html there's > this phrase: "The following binary expressions are evaluated in an > implementation-defined order". When I search it, with quotes, it > leads to www.digitalmars.com/d/2.0/.../std_algorithm.html (not what I > was looking for) > > However, when searching that same phrase in Google (not the Goolge > search-box in digitalmars.com/d), the first result is the expression > page for D2, the second is the same one for D1, etc. > > Should I report a bug for this? I wanted to discuss it here first > because maybe somebody knows what's going on... You will probably find that when you have the correctly constructed query google is also easier to find things on the news groups. I also find google the easiest way to find anything on any site so I just use google otherwise I would be very busy reporting bugs / suggestions to every site I have ever searched.
Re: Triggers
Sjoerd van Leent Wrote:
> OK, to make matters worse.
>
> As I was reading so many things about properties, keywords and a bunch of
> other interesting things, perhaps triggers.
>
> Triggers are, in my opinion, functions that act as delegates, and are called
> before or after one or more other functions. Maybe we can do something with
> this? It would introduce some aspect programming to D.
>
> file 1:
>
> class Foo
> {
> int mybar;
> int myother;
>
> void bar(int i)
> {
> mybar = i;
> }
>
>
> void other(int i)
> {
> myother = i;
> }
> }
>
>
> file 2:
>
> trigger(before) : "*.void * (int *)"
> {
> writefln("calling ", this.currentFunctionName);
> }
>
> trigger(after) : "*.void * (int *)"
> {
> writefln("called ", this.currentFunctionName);
> }
>
>
> This might be something for D3 though...
You can already do something like that, although very hackish: turn on trace
profiling and override the prolog/epilog code from druntime (I think these are
called _trace_pro_n and _trace_epi_n, just grep the source for their syntax).
Just make *very* sure to use only naked declarations in these and any routine
they may call, or else you will just call back into _trace_pro_n until you get
a stack overflow.
Re: Iterators Must Go video online
On Mon, 03 Aug 2009 12:47:40 -0500 Andrei Alexandrescu wrote: > A while ago I mentioned the video of my BoostCon keynote "Iterators > Must Go" will be soon available online. Here it is: > > http://boostcon.blip.tv/ > > > Andrei I may have been mistaken but I thought I heard you say you re wrote the iterators as ranges twice. Once for D's std.range and once for C++ STL but I heard you then saying someone should re write STL. Do you have a re write of STL on the net anywhere?
Re: Naming things in Phobos - std.algorithm and writefln
Michel Fortin wrote:
> On 2009-08-05 03:29:11 -0400, Daniel Keep
> said:
>> "makeSplitter" is OK, but needlessly verbose.
>>
>> I think when you have a function whose only purpose is to construct
>> something, or is strictly or conceptually pure, it's OK to use a noun
>> for its name.
>
> Perhaps this rule should be added to the guideline then. But as it was
> said countless times in the all the threads about properties, many nouns
> are also verbs in English, and they can easily create confusion in this
> situation.
Yes, there are lots of nouns that are also verbs but "splitter" isn't
one of them. Just because they exist doesn't mean you can't ever use
nouns without qualification.
> Calling directly the constructor of Splitter would be great, but alas
> you can't deduce struct template aruments from its constructor and have
> to rely on a separate function.
My point was that there would be ZERO difference assuming we could;
arguing that just because it's implemented using a function that it must
be extra verbose is just silly.
> "makeSplitter" is the less consusing one in my opinion.
It's more accurate but, as I said, needlessly verbose. "splitter" is a
noun and it's hard to even deliberately think of ways to misinterpret
it. I mean, we use "sin(x)" without problems although it could also
have been written "computeSineOf(x)".
Except, of course, then you'd have a hoard of angry numerical
programmers knocking on your door with torches and pitchforks.
> Altenatively, we could rename "splitter" to "split". After all, the
> documentation says "Splits a range using another range or an element as
> a separator." If you want an array, you write split(...).toArray(), or
> perhaps better would be to have the resulting range implicitly-casted to
> an array when needed (but are implicit casts still in the pipe now that
> we have alias this?).
No, naming it "split" implies that it's performing the "split" action on
its arguments, which is *isn't*. Implying that it does *anything* in
the function name is misleading since nothing actually takes place until
*after* the function has returned.
>>> ...
>>
>> I think that's a problem with the guidelines. Anyone trying to turn D
>> into Java should be shot. It's not clear what "fln" means, true...
>> until you look up ANY output function with a f, ln or fln suffix and
>> then it's obvious.
>
> Please, don't make unsupported accusations as an excuse to shoot people.
> Instead, you should say what you dislike about Java and explain why. (My
> guess is you find System.Out.println too long.)
I was attempting to be jovial. [1]
Java and, to a lesser extent, .NET have this serious problem where all
of the names are needlessly long and verbose. This makes writing actual
code tedious and annoying. No, I do not use an IDE and I shouldn't NEED
autocomplete to be able to write code efficiently.
Also, making code longer means less of it fits on a line, less on a page
and most critically of all: less in your brain. Look at legalese: it's
incredibly accurate but also almost impossible to read. I've found that
it takes so long to read a sentence that by the time you finish, you've
forgotten what it was about.
Just because a name is unambiguous doesn't automatically make it good.
writefln is a good name because the root indicates what it does "it
writes to something", the f comes from printf and ln is used in a few
languages.
What's more, even if you don't know what those suffixes mean initially,
because they're used *consistently*, once you learn it you can apply it
all over the place.
And best of all: it's short to type. [2]
> I'm tring to see how I can adapt the guidelines to accept this function
> ("writefln") and I can't see any sensible rule I could add. Any idea?
"Short suffixes are good when applied consistently across multiple
symbols."?
> Alternatively, "writefln" could be an exception to the rules, but then
> the exception would need a better rationale than "it shouldn't look like
> Java". I mean, if Phobos makes unjustified exceptions to its naming
> conventions here and there for no good other reason than "it looks
> good", it breaks the concistency and makes function names less
> predictable and less readable.
As I indicated above, it's descriptive, consistent and short; a great name.
> But it'd be easier to rename the functions to fit the convention:
I find that supposition hard to accept.
> ...
>
> That way, if someone writes logging functions one day that takes
> formatted strings in the same way, he can reuse the convention:
>
> log
> logLine
> logFormat
> logLineFormat
>
> instead of "log", "logln", "logf", and "logfln". If you create a hash
> function, you can reuse the pattern too:
>
> hash
> hashLine
> hashFormat
> hashLineFormat
>
> instead of "hash", "hashln", "hashf" and "hashfln". And it goes on.
How is this an improvement? If we accept that people know what the "f"
and "ln" suffixes mean (and
Re: Naming things in Phobos - std.algorithm and writefln
Michel Fortin wrote: Alternatively, "writefln" could be an exception to the rules, but then the exception would need a better rationale than "it shouldn't look like Java". I mean, if Phobos makes unjustified exceptions to its naming conventions here and there for no good other reason than "it looks good", it breaks the concistency and makes function names less predictable and less readable. I agree that Phobos' names could use a good overhaul. That would make it easier for growing it too. Certain names could be kept short and intuitive although they don't fit common conventions. Andrei
Triggers
OK, to make matters worse.
As I was reading so many things about properties, keywords and a bunch of other
interesting things, perhaps triggers.
Triggers are, in my opinion, functions that act as delegates, and are called
before or after one or more other functions. Maybe we can do something with
this? It would introduce some aspect programming to D.
file 1:
class Foo
{
int mybar;
int myother;
void bar(int i)
{
mybar = i;
}
void other(int i)
{
myother = i;
}
}
file 2:
trigger(before) : "*.void * (int *)"
{
writefln("calling ", this.currentFunctionName);
}
trigger(after) : "*.void * (int *)"
{
writefln("called ", this.currentFunctionName);
}
This might be something for D3 though...
scope, inline, optimizations, scoped attributes
In D there's no "inline" (even if it sometimes useful, see the
pragma(allow_inline) of LDC, that's useful to force the inlining of functions
that contain asm) because compilers are today regarded as smart enough to
inline functions automatically when they see it's an advantage (sometimes they
are wrong, it's an heuristics).
But D contains "scope" to suggest the compiler to stack allocate a class
instance. Recently LDC is (sometimes) able to find by itself when an object
behaves well enough to perform its automatic and invisible scoping (in such
situation LDC adds an invisible stack-allocated variable that's the reference
to the stack-allocated object, such reference is also used if you reassign the
reference). So eventually D2 may choose to deprecate this usage of "scope"
leaving such decision fully to the compiler, as in the inline case, reducing
the work of the programmer a bit. Java compilers too perform such automatic
stack allocation (and HotSpot is a bit better than LDC still in such regard,
but I have a simple idea that may put LDC almost on par on this,
http://www.dsource.org/projects/ldc/ticket/339 ).
About this topic, time ago some people have asked for a way to add "scope" to
object class members, like this:
class Foo {
int x;
this(int xx) { this.x = xx; }
}
class Bar {
scope Foo f; // ***
int y;
this(int xx, int yy) {
this.f = new Foo(xx);
this.y = yy;
}
}
void main() {
auto b = new Bar(10, 20);
printf("%d %d\n", b.f.x, b.y);
}
This kind of optimization can be useful, this is shown in an example of small
raytracing benchmark (I can offer all the code if you need it):
Timings, seconds, best of 3, on a 32 bit Ubuntu-like Linux:
ray1_scoped_cpp 7.99
ray1_d 8.51 (LDC Aug 3 2009)
ray1_cpp 8.66
In "ray1_scoped_cpp" an object that's a class attribute is scoped, in ray1_cpp
it is not as in the D code (Walter once said that D is slower than C++: it's
often no longer true if you use LDC and if the code is the "same" (same = after
compiler optimizations)).
Instead of adding "scope" to Foo f; inside Bar, a different possibility is to
add LDC (and other future _D1_ compilers) a way to perform such optimization by
themselves, in a transparent way (such "transparency" is sometimes dangerous,
also because abstractions sometimes leak, but I assume it may be worth it
anyway). This is not an easy thing to implement, but I think it can be done.
The size of the class changes, the position of its fields changes, etc. There
are some things that have to be special-cased to allow this optimization to
produce programs that work correctly. An alternative solution that probably
requires less special-casing is to add an invisible field to the class that has
such scoped object member, this invisible field is the reference, that can be
reassigned, etc. (Even with this extra field I think it can result as an
optimization still, because there's more cache coherence, less total memory
allocated, LDC is probably able to optimize away some deferences !
of this class reference, etc).
Bye,
bearophile
Re: Naming things in Phobos - std.algorithm and writefln
Michel Fortin Wrote:
> >> As you know, I tried to write some guidelines[1] for naming things in D.
> >> Those guidelines looks well at first glance, but then you look at Phobos
> >> and you see that half of it use some arbitrary naming rules. Take
> >> "writefln" for instance: following my guidelines (as they are currently
> >> written) it should be renamed to something like "writeFormattedLine".
> >>
> >> [1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines>
> >
> > I think that's a problem with the guidelines. Anyone trying to turn D
> > into Java should be shot. It's not clear what "fln" means, true...
> > until you look up ANY output function with a f, ln or fln suffix and
> > then it's obvious.
>
> Please, don't make unsupported accusations as an excuse to shoot
> people. Instead, you should say what you dislike about Java and explain
> why. (My guess is you find System.Out.println too long.)
>
> I'm tring to see how I can adapt the guidelines to accept this function
> ("writefln") and I can't see any sensible rule I could add. Any idea?
>
> Alternatively, "writefln" could be an exception to the rules, but then
> the exception would need a better rationale than "it shouldn't look
> like Java". I mean, if Phobos makes unjustified exceptions to its
> naming conventions here and there for no good other reason than "it
> looks good", it breaks the concistency and makes function names less
> predictable and less readable.
>
> But it'd be easier to rename the functions to fit the convention:
>
> write -> write
> writeln -> writeLine
> writef-> writeFormat
> writefln -> writeLineFormat
>
> That way, if someone writes logging functions one day that takes
> formatted strings in the same way, he can reuse the convention:
>
> log
> logLine
> logFormat
> logLineFormat
>
> instead of "log", "logln", "logf", and "logfln". If you create a hash
> function, you can reuse the pattern too:
>
> hash
> hashLine
> hashFormat
> hashLineFormat
>
> instead of "hash", "hashln", "hashf" and "hashfln". And it goes on.
>
>
> >> ...
> >>
> >> What does everyone thinks about all this?
> >
> > I think it's a good idea to have a good style guide; but rules only
> > exist to make you think once before you break them. :)
>
> By "thinking twice" you should be able to come with a good
> justification; and if you can't then you should follow the rules.
> That's fine by me.
>
I think the real problem underlying the wish to use writefln versus
writeFormatLine (or anything like that), is that C programmers are in the habit
of using very short names.
But in my personal experience, most languages I use have a short formatted
version of write..., probably because it is necessary many times. Although I
agree that writefln, if adapted to the convention, should become
writeFormatLine, I also understand the clumsiness of writing it.
As far as I know, writefln is with us for a very long time. But it doesn't say
that it should or should not be changed. I think that no one has been given any
thought to it.
I want to know: do we use writefln often, or is it just convenience, when
writing out a something. I would imagine to have a formatter object that
accepts a delegate which writes strings. I would as thus remove writefln, and
just have the function write.
The formatter object could be reponsible to actually use it, for example:
Formatter.out(write, "%s%s", "Hello World", newline)
The function "write" can still be used to emit directly, such as:
write("Hello world\n")
I think this is the real problem of writefln. Not the convention, but the
approach.
Re: Naming things in Phobos - std.algorithm and writefln
Michel Fortin wrote: In std.algorithm, wouldn't it be clearer if "splitter" was called "splitLazily" or "splitLazy"? "splitter" is a noun, but as a function shouldn't it be a verb. "makeSplitter" or "toSplitter" perhaps? And what about the "array" function? Wouldn't it be clearer if it was "toArray" so we know we're preforming a convertion? As you know, I tried to write some guidelines[1] for naming things in D. Those guidelines looks well at first glance, but then you look at Phobos and you see that half of it use some arbitrary naming rules. Take "writefln" for instance: following my guidelines (as they are currently written) it should be renamed to something like "writeFormattedLine". There should be an exception for functions which are analogous to C functions and have well established names in C. (eg, printf). Probably for famous functions in other languages, too. writeln() comes from Pascal, analogy with printf gives us writefln(). So that one's OK. I could take a look at std.algorithm and other modules in Phobos to list inconsistencies with the guidelines. From this we could make improvements both to the guideline document and the API. But before going too deep I think we should start with a few examples, such as those above, and see what to do with them. What does everyone thinks about all this? Yes, this is great. A review process would be very valuable. Please check the names in std.math. For the most part I have taken the names from the IEEE754-2008 standard, but please make suggestions. As we move towards finalizing D2.0, that module should be one of the first to have its interface frozen.
Re: Naming things in Phobos - std.algorithm and writefln
On 2009-08-05 03:49:34 -0400, Robert Fraser said: Michel Fortin wrote: As you know, I tried to write some guidelines[1] for naming things in D. Those guidelines looks well at first glance, but then you look at Phobos and you see that half of it use some arbitrary naming rules. Take "writefln" for instance: following my guidelines (as they are currently written) it should be renamed to something like "writeFormattedLine". [1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines> I think naming guidelines aren't a bad thing, but they can be taken too far. We use an automated tool at work to check code and today I was forced to change the name of some classes because they ended in "Queue" or "Dictionary" and "fix the spelling" of "Http" because it thought it was Hungarian notation. That's indeed ridiculous. But that's not an example of guidelines gone too far, that's an example of a silly tool that's not even able to apply guidelines correctly. The guidelines I wrote are human-verifiable, not machine verifiable, and sometime require judgement. Exceptions to the guidelines are fine, as long as they have a good rationale supporting them. Even better than making exceptions to the guidelines is creating standardized patterns and adding it to the guideline. as I did with "to" functions (they don't start with a verb like the guideline says, but they are used as a convention for convertion functions). -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Naming things in Phobos - std.algorithm and writefln
On 2009-08-05 03:29:11 -0400, Daniel Keep said:
Michel Fortin wrote:
In std.algorithm, wouldn't it be clearer if "splitter" was called
"splitLazily" or "splitLazy"? "splitter" is a noun, but as a function
shouldn't it be a verb. "makeSplitter" or "toSplitter" perhaps?
This is a specious argument.
splitter's only purpose is to return an instance of a Splitter struct.
You can't call it "splitLazily" or "splitLazy" because that implies that
the function is doing work, when it really isn't.
I agree, those aren't very good names.
Following this line of reasoning, all structs should be renamed to verbs.
"makeSplitter" is OK, but needlessly verbose.
I think when you have a function whose only purpose is to construct
something, or is strictly or conceptually pure, it's OK to use a noun
for its name.
Perhaps this rule should be added to the guideline then. But as it was
said countless times in the all the threads about properties, many
nouns are also verbs in English, and they can easily create confusion
in this situation.
Calling directly the constructor of Splitter would be great, but alas
you can't deduce struct template aruments from its constructor and have
to rely on a separate function.
"makeSplitter" is the less consusing one in my opinion.
Altenatively, we could rename "splitter" to "split". After all, the
documentation says "Splits a range using another range or an element as
a separator." If you want an array, you write split(...).toArray(), or
perhaps better would be to have the resulting range implicitly-casted
to an array when needed (but are implicit casts still in the pipe now
that we have alias this?).
And what about the "array" function? Wouldn't it be clearer if it was
"toArray" so we know we're preforming a convertion?
Same reasoning as above. toArray is also fine; it's possibly more in
line with other conversion functions.
As you know, I tried to write some guidelines[1] for naming things in D.
Those guidelines looks well at first glance, but then you look at Phobos
and you see that half of it use some arbitrary naming rules. Take
"writefln" for instance: following my guidelines (as they are currently
written) it should be renamed to something like "writeFormattedLine".
[1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines>
I think that's a problem with the guidelines. Anyone trying to turn D
into Java should be shot. It's not clear what "fln" means, true...
until you look up ANY output function with a f, ln or fln suffix and
then it's obvious.
Please, don't make unsupported accusations as an excuse to shoot
people. Instead, you should say what you dislike about Java and explain
why. (My guess is you find System.Out.println too long.)
I'm tring to see how I can adapt the guidelines to accept this function
("writefln") and I can't see any sensible rule I could add. Any idea?
Alternatively, "writefln" could be an exception to the rules, but then
the exception would need a better rationale than "it shouldn't look
like Java". I mean, if Phobos makes unjustified exceptions to its
naming conventions here and there for no good other reason than "it
looks good", it breaks the concistency and makes function names less
predictable and less readable.
But it'd be easier to rename the functions to fit the convention:
write -> write
writeln -> writeLine
writef-> writeFormat
writefln -> writeLineFormat
That way, if someone writes logging functions one day that takes
formatted strings in the same way, he can reuse the convention:
log
logLine
logFormat
logLineFormat
instead of "log", "logln", "logf", and "logfln". If you create a hash
function, you can reuse the pattern too:
hash
hashLine
hashFormat
hashLineFormat
instead of "hash", "hashln", "hashf" and "hashfln". And it goes on.
...
What does everyone thinks about all this?
I think it's a good idea to have a good style guide; but rules only
exist to make you think once before you break them. :)
By "thinking twice" you should be able to come with a good
justification; and if you can't then you should follow the rules.
That's fine by me.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Searching the digitalmars.com/d website
Sorry for brining this topic again, but there's something that really worries me (not that I cannot sleep at night, but...) Take this page: http://www.digitalmars.com/d/2.0/function.html There are some big headers there: "pure functions", "nothrow functions", "ref functions", "virtual functions", "Function Inheritance and Overriding", "Function Overloading", etc. Searching *any* of those phrases (without the quotes) leads to results other than that page. Searching them with quotes further restrict the results, sometimes resulting in none. Maybe that specific page is not being indexed by that search box. But it doesn't seem to be the case. I tried other random searches over other page headers: - "Linkage Attribute" in http://www.digitalmars.com/d/2.0/attribute.html: not what I was looking for. - "Properties for Floating Point Types" in http://www.digitalmars.com/d/2.0/property.html: not what I was looking for. - "Class Properties" in http://www.digitalmars.com/d/2.0/class.html: not what I was looking for. - getVirtualFunctions in http://www.digitalmars.com/d/2.0/traits.html: found it. - "Order Of Evaluation" in http://www.digitalmars.com/d/2.0/expression.html: no... I'm starting to think that some pages aren't being indexed. For example in http://www.digitalmars.com/d/2.0/expression.html there's this phrase: "The following binary expressions are evaluated in an implementation-defined order". When I search it, with quotes, it leads to www.digitalmars.com/d/2.0/.../std_algorithm.html (not what I was looking for) However, when searching that same phrase in Google (not the Goolge search-box in digitalmars.com/d), the first result is the expression page for D2, the second is the same one for D1, etc. Should I report a bug for this? I wanted to discuss it here first because maybe somebody knows what's going on...
Re: DIP6: Attributes
On Wed, 05 Aug 2009 07:20:38 +0400, Benji Smith wrote: Frank Benoit wrote: Andrei Alexandrescu schrieb: Ary Borenszweig wrote: call!(foo)(5, "hello") with varaidic args? Well some don't like to need to remember the order of arguments. Andrei Assigning the argument by name instead of order has two other benefits, i can think of... 1. on the call side, it is documented for what the given values are used. 2. it may be possible to let all parameters have default values and for example just give a value for the last parameter. This is not possible with just the parameter order. But these aren't issues with reflection. These are just the same function calling rules applied elsewhere in the language: 1) If you want to call a function: you must know its name. 2) If you want to pass parameters: you must know the correct order. I can't imagine a circumstance where someone uses reflection to call a function and knows how to create the correct set of arguments, but doesn't know what order to put them in. --benji They are mostly used with optional parameters: void foo(int x = -1, int y = 42, bool b = false); foo(b: true);
Re: DIP6: Attributes
Steven Schveighoffer Wrote:
> What I'd like to see is something like this possible:
>
> void foo (int timeout, string bar, float f = 4.0);
>
> void foo(int timeout);
>
> call!(foo)("timeout=5,bar=\"hello\"");
>
> Taking into account the default value of f, what the parameters are named,
> and which overload to call. I could certainly do it with C#.
In .net reflection needs no compile time support, it's fully runtime. You don't
always have full type information at compile time, unless you want to restrict
reflection to compile-everyting-to-one-big-pile scenario.
Re: Naming things in Phobos - std.algorithm and writefln
Michel Fortin wrote: As you know, I tried to write some guidelines[1] for naming things in D. Those guidelines looks well at first glance, but then you look at Phobos and you see that half of it use some arbitrary naming rules. Take "writefln" for instance: following my guidelines (as they are currently written) it should be renamed to something like "writeFormattedLine". [1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines> I think naming guidelines aren't a bad thing, but they can be taken too far. We use an automated tool at work to check code and today I was forced to change the name of some classes because they ended in "Queue" or "Dictionary" and "fix the spelling" of "Http" because it thought it was Hungarian notation.
Re: Contextualizing keywords
Daniel Keep wrote: true SomeType foo ... Ah, you saw the announcement for Microsoft's new .NET language?
Re: Naming things in Phobos - std.algorithm and writefln
Michel Fortin wrote: > In std.algorithm, wouldn't it be clearer if "splitter" was called > "splitLazily" or "splitLazy"? "splitter" is a noun, but as a function > shouldn't it be a verb. "makeSplitter" or "toSplitter" perhaps? This is a specious argument. splitter's only purpose is to return an instance of a Splitter struct. You can't call it "splitLazily" or "splitLazy" because that implies that the function is doing work, when it really isn't. Following this line of reasoning, all structs should be renamed to verbs. "makeSplitter" is OK, but needlessly verbose. I think when you have a function whose only purpose is to construct something, or is strictly or conceptually pure, it's OK to use a noun for its name. > And what about the "array" function? Wouldn't it be clearer if it was > "toArray" so we know we're preforming a convertion? Same reasoning as above. toArray is also fine; it's possibly more in line with other conversion functions. > As you know, I tried to write some guidelines[1] for naming things in D. > Those guidelines looks well at first glance, but then you look at Phobos > and you see that half of it use some arbitrary naming rules. Take > "writefln" for instance: following my guidelines (as they are currently > written) it should be renamed to something like "writeFormattedLine". > > [1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines> I think that's a problem with the guidelines. Anyone trying to turn D into Java should be shot. It's not clear what "fln" means, true... until you look up ANY output function with a f, ln or fln suffix and then it's obvious. > ... > > What does everyone thinks about all this? I think it's a good idea to have a good style guide; but rules only exist to make you think once before you break them. :)
