Re: new documentation format for std.algorithm

On 02/03/2011 02:24 AM, Jonathan M Davis wrote: The hyphenating looks horrible and is hard to read. I see no reason to make the category column worry about space so much. I would expect the functions column to be able to handle the width adjustment for various screen sizes. Screenshot:http://is.

Re: D vs Go on reddit

On 02/02/2011 10:37 PM, bearophile wrote: If a person looks at the history of computer languages, she sees thousands of languages. Many of them were lot of work to be created, and most of them have failed, over and over again. This has happened even to languages better than many other language

Re: D vs Go on reddit

On 02/03/2011 12:31 AM, bearophile wrote: Walter: http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0 I have one comment about one thing said by bnolsen: Simplicity + Orthogonality == win.< I would like people who state such phrases to all

Re: new documentation format for std.algorithm

On 02/02/2011 09:40 PM, "Jérôme M. Berger" wrote: Andrei Alexandrescu wrote: I'm not sure about that. Facebook's site is professionally designed and I think they use fixed font sizes all over the place. "Professionally designed" does not mean that they did the job right!

Re: new documentation format for std.algorithm

On 02/02/2011 08:41 PM, Denis Koroskin wrote: On Wed, 02 Feb 2011 19:00:20 +0300, Andrei Alexandrescu wrote: On 2/2/11 7:07 AM, spir wrote: On 02/02/2011 09:45 AM, Andrei Alexandrescu wrote: Following ideas and advice from this newsgroup, I have a draft at http://d-programming-language.org

Re: new documentation format for std.algorithm

On 02/02/2011 08:12 PM, Andrei Alexandrescu wrote: On 2/2/11 2:45 AM, Andrei Alexandrescu wrote: Following ideas and advice from this newsgroup, I have a draft at http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html There are two tables, one with just the names and the othe

Re: Having fun making tutorials

On 02/02/2011 07:12 PM, Andrej Mitrovic wrote: If someone makes a mistake when writing a tutorial, there's always someone more knowledgeable that can correct the errors ... instead of criticizing the original author ;-) That's the great thing about wiki's. Yop! Denis -- _ v

Re: new documentation format for std.algorithm

On 02/02/2011 05:05 PM, Daniel Gibson wrote: I don't understand why cmp, equal, isSorted, ... are in the "Mutations" category. what about an 'information' category? I use that word to categorise type functionality when there are numerous methods, seems to work fine. Typically '==', cmp, cont

Re: new documentation format for std.algorithm

On 02/02/2011 05:44 PM, Adam Ruppe wrote: I also moved the brief description from the table to the first line of the ddoc. The ddoc spec already describes the first paragraph as being a summary, with the following paragraphs as a separate description, so we

Re: new documentation format for std.algorithm

On 02/02/2011 05:00 PM, Andrei Alexandrescu wrote: On 2/2/11 7:07 AM, spir wrote: On 02/02/2011 09:45 AM, Andrei Alexandrescu wrote: Following ideas and advice from this newsgroup, I have a draft at http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html There are two tables

Re: new documentation format for std.algorithm

On 02/02/2011 04:58 PM, Andrei Alexandrescu wrote: On 2/2/11 6:47 AM, spir wrote: On 02/02/2011 11:08 AM, bearophile wrote: BlazingWhitester: It looks realy nice! I agree, it's a clear improvement. But brief description table could use some spacing between descriptions. It's

Re: new documentation format for std.algorithm

On 02/02/2011 04:55 PM, Andrei Alexandrescu wrote: I also agree with what others said about needing a better visual boundary between the different descriptions. I'll look into this. I saw arguments against alternating colors. Also, horizontal lines throughout would be ugly. Agreed. More id

Re: new documentation format for std.algorithm

On 02/02/2011 02:07 PM, spir wrote: On 02/02/2011 09:45 AM, Andrei Alexandrescu wrote: Following ideas and advice from this newsgroup, I have a draft at http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html There are two tables, one with just the names and the other with

Re: new documentation format for std.algorithm

On 02/02/2011 09:45 AM, Andrei Alexandrescu wrote: Following ideas and advice from this newsgroup, I have a draft at http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html There are two tables, one with just the names and the other with names and a brief description. Let me kn

Re: new documentation format for std.algorithm

On 02/02/2011 12:24 PM, Denis Koroskin wrote: On Wed, 02 Feb 2011 14:06:11 +0300, Magnus Lie Hetland wrote: I think perhaps some adjustments could be made to the layout, to make it more suitable to narrow(ish) browser windows (c.f., the discussio about 80 columns -- without starting a huge th

Re: new documentation format for std.algorithm

On 02/02/2011 11:08 AM, bearophile wrote: BlazingWhitester: It looks realy nice! I agree, it's a clear improvement. But brief description table could use some spacing between descriptions. It's a lilttle hard to read. Instead of that I suggest to give an alternating white - light cyan ba

Re: new documentation format for std.algorithm

On 02/02/2011 09:45 AM, Andrei Alexandrescu wrote: Following ideas and advice from this newsgroup, I have a draft at http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html There are two tables, one with just the names and the other with names and a brief description. Let me kn

Re: How many HOFs in Phobos?

On 02/02/2011 02:17 AM, bearophile wrote: But there are other HOFs that may be useful (they are in dlibs1 too): - "nest" (or iterate), to apply one function many times: nest(sin, 0.2, 4) === sin(sin(sin(sin(0.2 'iterate' would be great if it didn't have a different meaning in programming

Re: Decision on container design

On 02/01/2011 05:00 PM, Andrei Alexandrescu wrote: Regarding the general issue that someone makes an informal proposal (either here, as a DIP, or on the Phobos mailing list), followed by a thundering silence: I believe that a good technique is to formalize the proposal review process, which has b

Re: Would user polls be useful? (Was: Re: std.unittests [updated] for review)

On 02/01/2011 12:49 AM, Jens Mueller wrote: spir wrote: On 01/30/2011 01:13 PM, Jens Mueller wrote: I do not like putting it in std.exception. Maybe the name std.unittest is also not good. I would propose std.assert if assert wasn't a keyword. [...] I would_not_ expect helpers for wr

Re: (Was: On 80 columns should (not) be enough for everyone)

On 01/31/2011 11:33 PM, "Jérôme M. Berger" wrote: Nope it wraps to the same indent level as the original line, so you do not see at a glance that a line is wrapped. It shows it's a wrapped line using a dedicated "wrapping-arrow" sign. I never use this feature for code, though. Denis

Re: (Was: On 80 columns should (not) be enough for everyone)

On 01/31/2011 08:32 PM, Jonathan M Davis wrote: At minimum, it needs to be smarter about user-defined types. The functions for a class or struct should not be grouped with free functions. They should be grouped with the type that they're in._That_, at least, should be automatable, Isn't that's

Re: On 80 columns should (not) be enough for everyone

On 01/30/2011 10:29 PM, Nick Sabalausky wrote: void main() { void foo() { while(true) if(done) { } } } I'm a big fan of "stacking" flow-control statements like that whenever the outer statements don't have anything else in their body. Like this (st

Re: (Was: On 80 columns should (not) be enough for everyone)

On 01/30/2011 09:32 PM, "Jérôme M. Berger" wrote: foobar wrote: Tomek Sowiński Wrote: Andrej Mitrovic napisał: If you really want to set up a column limit that *everyone* has to abide to, then make a poll to see what everyone can agree on. Actually that's a splendid idea. Let's take it eas

Re: (Was: On 80 columns should (not) be enough for everyone)

On 01/31/2011 07:38 PM, foobar wrote: I keep taking about the API while you keep talking about its implementation. D needs to cater for different kinds of people, not just American born C++ guru programmers, but a diverse community of programmers with different programming backgrounds (that i

Re: (Was: On 80 columns should (not) be enough for everyone)

On 01/30/2011 10:18 PM, foobar wrote: Right, so does that mean it should be made_less_ readable by a diverse community of people? I have no issue with any style Andrei or others use when they code for themselves, be it 10 characters per row or 1000. I do place a MUCH higher weight on making th

Re: (Was: On 80 columns should (not) be enough for everyone)

On 01/30/2011 07:55 PM, Tomek Sowiński wrote: Andrej Mitrovic napisał: If you really want to set up a column limit that *everyone* has to abide to, then make a poll to see what everyone can agree on. Actually that's a splendid idea. Let's take it easy. Regardless of that silly beef I'm real

Re: On 80 columns should (not) be enough for everyone

On 01/31/2011 06:54 PM, Ulrik Mikaelsson wrote: I share most of Ulrik mentions. I'm not sure whether text-books and program-code are really comparable in this respect. Even if they were (which is imo absurd to state), what would count is not column number, but content length -- which is diff

Re: On 80 columns should (not) be enough for everyone

On 01/30/2011 07:27 PM, Walter Bright wrote: Andrej Mitrovic wrote: 80 columns wasn't determined by some scientific method to be a good size for code, it's a product of limitations of the older generation hardware. 80 columns came from how many characters would fit on a standard size 8.5*11 sh

Re: std.unittests [updated] for review

On 01/30/2011 02:13 PM, Jens Mueller wrote: The only argument against putting in its own module is it's size. That seems to be your main point. I think putting something in new module should mainly be concerned with separating stuff logically. Later on it should be easy to add a new module that i

Re: std.unittests [updated] for review

On 01/30/2011 01:13 PM, Jens Mueller wrote: I do not like putting it in std.exception. Maybe the name std.unittest is also not good. I would propose std.assert if assert wasn't a keyword. [...] I would_not_ expect helpers for writing assertions (Assert_Error_) in a module named std.exception.

Re: "scope" and "delete" are being removed, but not type-safe variadic templates?

On 01/31/2011 11:10 AM, %u wrote: Hi, I just realized something: If the delete keyword is being removed because it's dangerous, and if the scope storage class is being removed because of the same dangling reference problem, how come int[] global_var; void foo(int[] args...) { global_v

Re: Decision on container design

On 01/29/2011 06:09 PM, Simon Buerger wrote: Things to note: * container should be named with respect to their use, not the implementation. "HashSet" is a bad name, because the user shouldnt care about the implemenation. * unordered sets are used more often than ordered. So it should be "Set/Ord

Re: d-programming-language.org

On 01/30/2011 09:03 AM, Andrei Alexandrescu wrote: In agreement with Walter, I removed the Digitalmars reference. The message is simple - D has long become an entity independent from the company that created it. (However, this makes the page header look different and probably less visually appeal

Re: Suggestion: New D front page

On 01/29/2011 04:04 PM, David Gileadi wrote: I like it. As the guy responsible for the rather "dark and foreboding" current look and feel of the current d-programming-language.org I'd be happy to work to make this fit the current look and feel as well as alter the look and feel to match this dir

Re: Suggestion: New D front page

On 01/29/2011 01:56 PM, Christopher Bergqvist wrote: Hi! I have been putting some free time into creating a "design skeleton" for a new http://d-programming-language.org front page: http://digitalpoetry.se/D%20website/D%20overview%20design.png My main con

non-ref null arrays [was: Re: Decision on container design]

On 01/29/2011 01:01 AM, bearophile wrote: Built-in AAs are currently broken and in need to be fixed: import std.stdio: writeln; void foo(int[int] aa, int n) { aa[n] = n; } void main() { int[int] a; foo(a, 0); writeln(a); a[1] = 1; foo(a, 2); writeln(a); } Bye,

Re: Is D still alive?

On 01/28/2011 12:36 PM, bearophile wrote: I think the problem here is that you are not using your D tools well enough yet: - Preconditions allow you to save some tests in your unittests, because you have less need to test many input boundary conditions. - Postconditions are useful to save some

Re: Is D still alive?

On 01/27/2011 01:24 PM, Mafi wrote: Am 27.01.2011 01:41, schrieb spir: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though,

Re: Is D still alive?

On 01/27/2011 04:06 AM, Jonathan M Davis wrote: Clearly, if you think that not being strict about indices is a good idea, you're either dealing with very different circumstances than I have and/or you're coding very differently. Regardless, since it's trivial to create a wrapper that does what y

Re: Is D still alive?

On 01/27/2011 02:11 AM, Jonathan M Davis wrote: On Wednesday, January 26, 2011 16:41:10 spir wrote: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But au

Re: More on the necessity and difficulty of a package management system

On 01/26/2011 11:45 PM, Andrei Alexandrescu wrote: Seems to be unduly difficult in Python: http://www.google.com/buzz/michael.bruntonspall/AcMtiMEUgZ2/Packaging-and-deploying-python-web-apps Yes, experienced. Related, but distinct, difficulty with intra-package import (inter-module references

Re: Is D still alive?

On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays

Re: immutable

On 01/26/2011 10:21 PM, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 16:13:41 -0500, Trass3r wrote: (readln only uses ~= on buf, it doesn't change the original string) What? Why does it take a ref argument then? If it doesn't overwrite the buffer passed in, there is no point in giving it

Re: More Phobos testing

On 01/26/2011 01:56 PM, bearophile wrote: Now and then I try to use the std.algorithm/std.range parts of Phobos2 to see how they are going and developing. Here I have found Python3 code to compute the Pascal triangle: [...] Some notes on the D2 version: 1) In Python I am used to think of highe

Re: const/immutable member functions

On 01/26/2011 11:02 AM, Kagamin wrote: This "problem" happens because D belongs to the C-family of languages which puts the return type_before_ the function name. > > Languages that don't follow this syntactic convention (some would call it a mistake) have it very consistent and readable: >

Re: Precomposed Character & Grapheme on wikipedia

On 01/25/2011 10:43 PM, Ali Çehreli wrote: Nick Sabalausky wrote: "spir" wrote in message > This article brought me to http://en.wikipedia.org/wiki/Grapheme. Seems I > was partially wrong in stating that using "grapheme" to denote what we > commonly thi

Precomposed Character & Grapheme on wikipedia

Hello, I stepped on wikipedia's article http://en.wikipedia.org/wiki/Precomposed_character which is, imo, excellent. (It does not (yet) cope with consequences in programming with Unicode that we debated on this list.) A enigmatic point is "Precomposed characters are the legacy solution for re

Re: Showing unittest in documentation (Was Re: std.unittests

On 01/25/2011 11:10 AM, foobar wrote: The simple syntax of > > /++ Example +/ > unittest > { > } > > > making that unittest block go in the documentation of the preceding function > should work just fine. We already have /++ Ditto +/ which puts a function in with > the preceding function'

Re: const/immutable member functions

On 01/25/2011 10:45 AM, Jens Mueller wrote: I distinguish the following: type qualifiers: const, immutable, maybe also inout function attributes: pure, nothrow storage class: ref, in, out, static access qualifiers: private, package, protected, public, export Nice & clear classification. Then, i

Re: const/immutable member functions

On 01/24/2011 07:36 PM, bearophile wrote: What other people think about this situation? Do you want const/immutable to be required on the right, or do you prefer the current situation, or do you prefer some other solution? Comparing with C-like typing syntax that, I guess, are planned for dep

Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)

On 01/24/2011 10:03 PM, Andrei Alexandrescu wrote: One other thing, using writefln is considered bad form in unit tests (you want *no* output if the unit test works). But many examples might want to demonstrate how e.g. an object interacts with writefln. Any suggestions? The assert line above is

Re: ref param mismatch --> segfault

On 01/24/2011 10:07 PM, bearophile wrote: spir: Certainly ref qualifiers should be checked, shouldn't they? The situation indeed is somewhat special here. Foo getFoo(Token[] tokens, ref uint index) {...} Term[] getTerms (Term) (Term function (Token[], uint) parseFunc, Token[] t

ref param mismatch --> segfault

Hello, I was defining a (generic & higher-order) list-of-terms parsing func. It uses funcs which each parse a term of a given type from a token stream and advance a ref index. As you may note below, I initially forgot to 'ref' the index in the type of the parse func passed as param, in the gen

Re: replaceFirst, findPieces, and takeExactly

On 01/23/2011 06:21 AM, Andrei Alexandrescu wrote: On 1/22/11 10:59 PM, Jonathan M Davis wrote: This will be a _fantastic_ function to have. I think that I probably even have an enhancement request somewhere that includes such a function. It's far too common that you have to find something and y

Re: renamepalooza time

On 01/23/2011 09:13 AM, Ali Çehreli wrote: Agreed, but I will keep using an underscore after "is". Another reason why I do so is, when used with camelcase, that little "is" capitalizes the next word just to be consistent with the camelcase part of the naming conventions. When we have an attribute

Re: replaceFirst, findPieces, and takeExactly

On 01/23/2011 05:30 AM, Andrei Alexandrescu wrote: On 01/22/2011 10:16 PM, spir wrote: On 01/22/2011 10:27 PM, Andrei Alexandrescu wrote: The first abstraction is the takeExactly() function: http://d-programming-language.org/cutting-edge/phobos/std_range.html#takeExactly That function

Re: replaceFirst, findPieces, and takeExactly

On 01/23/2011 04:49 AM, Daniel Gibson wrote: splitAt is simply a Good Name! (even better than "tripartite" ;-) Also for finding it in list of funcs. Denis _ vita es estrany spir.wikidot.com To be honest, tripartite sounds kind of strange. I don't know why, but I think of spide

Re: replaceFirst, findPieces, and takeExactly

On 01/22/2011 10:27 PM, Andrei Alexandrescu wrote: The first abstraction is the takeExactly() function: http://d-programming-language.org/cutting-edge/phobos/std_range.html#takeExactly That function allows you to pick a determined number of elements from a range, assuming the range is never sh

Re: replaceFirst, findPieces, and takeExactly

On 01/23/2011 12:40 AM, so wrote: Yes, I'm absolutely in agreement with the naming (and thrilled too). I imagine a putative user looking through std.algorithm ("let's see... what find functions are out there?"). That makes findPieces easy to get to, whereas "trisect" would be oddly situated in th

Re: replaceFirst, findPieces, and takeExactly

On 01/23/2011 12:40 AM, so wrote: Yes, I'm absolutely in agreement with the naming (and thrilled too). I imagine a putative user looking through std.algorithm ("let's see... what find functions are out there?"). That makes findPieces easy to get to, whereas "trisect" would be oddly situated in th

Re: replaceFirst, findPieces, and takeExactly

On 01/22/2011 11:16 PM, bearophile wrote: That function allows you to pick a determined number of elements from a > range, assuming the range is never shorter than that. That sounds a bit > obscure, but plays a pivotal role in findParts() (which is the name I > settled on for the equivalent of

Re: renamepalooza time

On 01/23/2011 02:39 AM, Nick Sabalausky wrote: "so" wrote in message news:op.vpqi7ngy7dtt59@so-pc... I'm the same way. Plus, I find it really awkward to constantly type a bunch of underscores. It feels less like "typing" and more like "finger acobatics." It is worse for camelCase, Don't see

Re: renamepalooza time

On 01/23/2011 12:03 AM, Ali Çehreli wrote: Jonathan M Davis wrote: On Friday, January 21, 2011 13:30:11 Ali Çehreli wrote: Andrei Alexandrescu wrote: > iswhite I like separating is with an underscore, like most coding styles do: is_whitespace Warm and fuzzy... :) Most? I've never dealt wit

Re: more naming

On 01/22/2011 05:27 PM, Andrei Alexandrescu wrote: OK, so we have replace(haystack, needle, nail) which replaces _all_ occurrences of needle in haystack with nail. How would you call a function that replaces only the _first_ occurrence of needle with nail? Must be a distinct function, not a runt

string splitting funcs

While we're at tweaking std.string: When writing string libs or types (like Text recently), I implement 3 string splitting methods. This may --or not-- be useful for D's string module. The core point is: what to do with empty parts? They may be generated when: * the separator is present at ei

Re: Python's partition

On 01/22/2011 06:44 PM, Andrei Alexandrescu wrote: Looking through Python's string functions (http://docs.python.org/release/2.5.2/lib/string-methods.html) I noticed partition(): partition(sep) Split the string at the first occurrence of sep, and return a 3-tuple containing the part before the s

Re: DVCS

On 01/22/2011 10:34 AM, Vladimir Panteleev wrote: On Sat, 22 Jan 2011 08:35:55 +0200, Walter Bright wrote: The only real problem I've run into (so far) is the sunbird calendar has been unceremoniously dumped from Ubuntu. The data file for it is in some crappy binary format, so poof, there goes

Re: easy to upgrade OS (was Re: DVCS)

On 01/22/2011 09:58 AM, Walter Bright wrote: Gour wrote: I'm very seriously considering to put PC-BSD on my desktop and of several others in order to reduce my admin-time required to maint. all those machines. OSX is the only OS (besides DOS) I've had that had painless upgrades. Windows upgrad

Re: DVCS

On 01/22/2011 07:35 AM, Walter Bright wrote: I finally did do it, but as a clean install. I found an old 160G drive, wiped it, and installed 10.10 on it. (Amusingly, the "About Ubuntu" box says it's version 11.04, and /etc/issue says it's 10.10.) Same for me ;-) _ vita es estran

Re: renamepalooza time

On 01/22/2011 01:16 AM, Andrei Alexandrescu wrote: Ever since I worked with STL, I fell in love with names_with_underscores. I can't explain it, but my feeling is that code using that convention is calm and levelheaded. Camel case forces me to think of one-word names because at the second word so

Re: xxxInPlace or xxxCopy?

On 01/21/2011 10:03 PM, Jonathan M Davis wrote: I really don't find having functions returning results without altering their arguments as the normal case to be odd at all, let alone misleading, since that's what most functions actually do. Same for me. I don't find having this version as the n

Re: renamepalooza time

On 01/21/2011 10:46 PM, Tomek Sowiński wrote: So if not uppercase, what is the convention for constants then? And, to hair-split more, what is a constant to begin with? Would e.g. a big immutable configuration tree structure fall into that bucket? Or a logger object? Very personal def: I give

Re: renamepalooza time

On 01/22/2011 12:17 AM, bearophile wrote: > You are right. But I'd like to know why Phobos uses camelcase instead of underscores (as used in C and Python). I think variable names in camelcase are less noisy. I have used underscores for a long time, then had to switch to camelcase for conforma

Re: xxxInPlace or xxxCopy?

On 01/21/2011 09:21 PM, Jonathan M Davis wrote: The issue is when you don't look at the documentation or trying to avoid having to look at the documentation. If you see auto result = replace(str, "hello", "goodbye"); it's quite clear that a copy is taking place. And if a copy/slice is taking pl

Re: Potential patent issues

On 01/21/2011 09:18 PM, Daniel Gibson wrote: You're thinking of closures (which are also "delegates" in D), but D's delegates can also be used to simple point to a member of an object. It's kind of hidden in the definition: "Delegates to non-static nested functions contain two pieces of data: th

Re: xxxInPlace or xxxCopy?

On 01/21/2011 07:47 PM, so wrote: replace is clearer in the first case, because you're getting the return value. ... I am really trying hard to understand this, but your reasons for first is clearer then the second makes no sense to me i am sorry. I still think second is clearer, but whatever, a

Re: Potential patent issues

On 01/21/2011 03:51 PM, Don wrote: Don wrote: BlazingWhitester wrote: I spotted some patents that can theaten current DMD implementation. Wanted to clarify things. http://www.freepatentsonline.com/6185728.pdf - this patent describes method pointers implementation (delegates) This was obvious

Re: Constructors (starstruck noob from C++)

On 01/21/2011 05:27 PM, Robert Jacques wrote: On Fri, 21 Jan 2011 08:16:24 -0500, spir wrote: On 01/21/2011 06:28 AM, Robert Jacques wrote: void copyMembers(A)(A src, A tgt) if (is(A == class)) { tgt.tupleof = src.tupleof; } What about this feature in Object under name "copy&quo

Re: Constructors (starstruck noob from C++)

On 01/21/2011 01:29 PM, bearophile wrote: > spir: > >>> It's a shame we can't use .dup. It would look really nice in code. >> >> +++ > > Copying classes is not a so common need in D. As an example, I need a byPair() method for AAs more than dup for cl

Re: renamepalooza time

On 01/21/2011 10:05 AM, Lars T. Kyllingstad wrote: These should be expanded a bit and camelCased: LS:lineSep, lineSeparator PS:paragraphSep, paragraphSeparator Isn't there a rule that constants all fully uppercase? Denis _ vita es estrany spir.wikidot.com

Re: renamepalooza time

On 01/21/2011 10:14 AM, Jacob Carlborg wrote: ljustify -> leftJustify /justifyLeft rjustify -> rightJustify/justifyRight stripl -> stripLeft stripr -> striptRight Consistency. Eg: all qualifiers come first (like in english). Denis _ vita es estrany spir.wikidot.com

Re: renamepalooza time

On 01/21/2011 09:44 AM, Jonathan M Davis wrote: Well, entab, I'd argue_does_ follow the naming convention, because entab would be a verb, albeit a made up one. Certainly, en is a prefix, not another word, so I think that entab is fine. If that doesn't fly, then go with enTab, I guess, but I'd a

Re: renamepalooza time

On 01/21/2011 09:43 AM, Lutger Blijdestijn wrote: LS and PS: since these are constants, upper case is ok, although LS is inconsistent with std.path.linesep. Consistency across stdlib modules and with D builtin names (esp types) would be even more helpful than proper casing, imo. [Also: Is th

Re: renamepalooza time

On 01/21/2011 09:43 AM, Lutger Blijdestijn wrote: newline and whitespace: not sure how it is called in English, but these look like they have become single words and are fine. I would not make such exceptions because there is no rational criterion to determine which multiple-word terms have be

Re: Constructors (starstruck noob from C++)

On 01/21/2011 06:28 AM, Robert Jacques wrote: void copyMembers(A)(A src, A tgt) if (is(A == class)) { tgt.tupleof = src.tupleof; } What about this feature in Object under name "copy" or "dup"? Sure, it's not to be used evereday; but it's typcally the kind of routine that, when needed, we're v

back down on Earth [was: Re: Constructors...]

On 01/21/2011 04:02 AM, Andrei Alexandrescu wrote: That being said, it's not difficult to define a generic function that copies fields over from one class object to another. Here's a start: import std.stdio; void copyMembers(A)(A src, A tgt) if (is(A == class)) { foreach (e; __traits(allMe

Re: Constructors (starstruck noob from C++)

On 01/21/2011 04:48 AM, Andrej Mitrovic wrote: On 1/21/11, Andrei Alexandrescu wrote: I think copyMembers belongs to the standard library. I wanted to define a family of functions like it but never got around to it. It's a shame we can't use .dup. It would look really nice in code. +++ De

Re: xxxInPlace or xxxCopy?

On 01/20/2011 12:33 AM, Andrei Alexandrescu wrote: I'm consolidating some routines from std.string into std.array. They are specialized for operating on arrays, and include the likes of insert, remove, replace. One question is whether operations should be performed in place or on a copy. For exa

Re: xxxInPlace or xxxCopy?

On 01/20/2011 11:31 AM, bearophile wrote: > Andrej Mitrovic: > >> I think what might help out in D is if we had a way to mark some >> functions so the compiler guarantees that their return values *are >> not* to be discarded. For example, this code will compile: >> >> import std.stdio; >> import s

Re: filter!(not!(predicate))(someInputRange) does not compile

On 01/20/2011 02:19 AM, Jens Mueller wrote: Thanks. Can you elaborate a bit please? I wonder why the alias won't work. Because in your original version the alias line does not define a func, but a kind of constant symbol. A higher order func like filter expects a func as first arg, not a cons

Re: Another task

On 01/20/2011 11:12 AM, bearophile wrote: > And I suggest to add a third associative array member function that returns a range of key,value tuples, as in Python3. This allows to solve the task like this: > auto r = map!q{ tuple(a[0]*10, a[1]~a[1]) }(aa.byPair()); Yes, this is the only nice lo

Re: Potential patent issues

On 01/19/2011 10:09 PM, retard wrote: Wed, 19 Jan 2011 15:44:38 -0500, Nick Sabalausky wrote: "Andrej Mitrovic" wrote in message news:mailman.724.1295465996.4748.digitalmar...@puremagic.com... Or pack your bags and move to Europe. :p I thought Europe was getting software patents? It's the

Re: What Makes A Programming Language Good

On 01/19/2011 12:56 PM, bearophile wrote: spir: Because when a module defines a type Foo (or rather, it's what is exported), I like it to be called Foo.d. Generally D modules contain many types. Yep, but often one is the main exported element. When there are several, hopefully sen

Re: Fixes for http://d.puremagic.com/issues/show_bug.cgi?id=4883 coming

On 01/19/2011 10:20 AM, Andrei Alexandrescu wrote: I moved a bunch of functions from std.string to std.array and std.algorithsm. I did my best to minimize impact but there will be some effects on user code, particularly if it qualifies names explicitly. Hello Andrei, Will the online doc quickl

Re: What Makes A Programming Language Good

On 01/19/2011 05:16 AM, Jesse Phillips wrote: > This is what the "Open Scalable Language Toolchains" talk is about > http://vimeo.com/16069687 > > The idea is that the compile has the job of compiling the program and providing information about the program to allow other tools to make use of th

Re: What Makes A Programming Language Good

On 01/18/2011 07:10 PM, bearophile wrote: spir: The D styleguide requires on one hand capitalised names for types, and lowercase for filenames on the other. How are we supposed to make them match? Why do you want them to match? Because when a module defines a type Foo (or rather, it's

string repr & range levels [was: Re: VLERange: ...]

lisation can be applied at this level --and is necessary for the above kind of use case. But using it for operations requiring compare will typically also require "piling", that is the next level, if only to determine what is to be compared. 3) Graphemes: This is what the string type th

Re: VLERange: a range in between BidirectionalRange and RandomAccessRange

On 01/18/2011 06:11 AM, Ali Çehreli wrote: Thanks to all that has contributed, I am also following this thread with great interest. :) Michel Fortin wrote: > I mean, a grapheme is a slice of a string, can have multiple code points > (like a string), can be appended the same way as a string, ca

Re: Too much flexibility is dangerous for large systems

On 01/19/2011 01:26 AM, dsimcha wrote: On 1/18/2011 7:46 AM, spir wrote: Think at Lisp, for instance, probably one of the most simple languages ever. This simplicity, precisely, forces to create tons of abstraction levels just to define notions not present in the language --due to simplicity

<    1   2   3   4   5   6   7   8   9   10   >