www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - New std.uni: ready for more beating

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
Recap:
During a couple of rounds of the informal review new std.uni had its 
docs happily destroyed, and later re-written based on the feedback.

Notable changes:

- Fixed a couple of latent bugs (ouch!)

- unicode.xyz helper was redesigned to have a clear path for extension 
to properties other then binary ones. For instance to get all of code 
points with hangul syllable type L (leading Jamo):

auto leadingJamo = unicode.hangulSyllableType("L");

- Squeezed extra 31Kb slack from object-file size (32 bits, more on 64). 
Now all of the packed tables occupy around 350Kb (32bits) and
If you happen to know some tricks to reduce object file size (and in 
turn the executable size), please chime in.

Code & benchmark: https://github.com/blackwhale/gsoc-bench-2012

Docs: http://blackwhale.github.com/phobos/uni.html
(looks far better without the JS jump-table)

It's a standalone module at the moment. To use in place of current 
std.uni replace 'std.uni'->'uni' in your programs and compare the 
results. Make sure that both uni and unicode_tables modules are linked 
in, rdmd can take care of this dependency.

P.S. Time to go for the formal review?

P.P.S. Got to catch some sleep ...
-- 
Dmitry Olshansky
Jan 29 2013
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
30-Jan-2013 01:52, Dmitry Olshansky пишет:
 Recap:
 During a couple of rounds of the informal review new std.uni had its
 docs happily destroyed, and later re-written based on the feedback.
[snip]
 - Squeezed extra 31Kb slack from object-file size (32 bits, more on 64).
 Now all of the packed tables occupy around 350Kb (32bits) and
 If you happen to know some tricks to reduce object file size (and in
 turn the executable size), please chime in.
My post got lost in the ether apparently. And it even wasn't complete - and on 64bits it's 464Kb of tables alone. Needless to say I'm worried about these sizes getting too large given that D is pretty much statically linked ATM.
 Code & benchmark: https://github.com/blackwhale/gsoc-bench-2012

 Docs: http://blackwhale.github.com/phobos/uni.html
 (looks far better without the JS jump-table)

 It's a standalone module at the moment. To use in place of current
 std.uni replace 'std.uni'->'uni' in your programs and compare the
 results. Make sure that both uni and unicode_tables modules are linked
 in, rdmd can take care of this dependency.
Let me make it more explicit. I'm looking for a review manager and anybody willing to revive the review process instead of venting steam on proper property (pun intended) design and seeking a value in requiring parens on no-arg call (or proving otherwise). -- Dmitry Olshansky
Jan 31 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 31, 2013 at 11:27:57PM +0400, Dmitry Olshansky wrote:
 30-Jan-2013 01:52, Dmitry Olshansky пишет:
Recap:
During a couple of rounds of the informal review new std.uni had its
docs happily destroyed, and later re-written based on the feedback.
[snip]
- Squeezed extra 31Kb slack from object-file size (32 bits, more on
64).  Now all of the packed tables occupy around 350Kb (32bits) and
If you happen to know some tricks to reduce object file size (and in
turn the executable size), please chime in.
My post got lost in the ether apparently. And it even wasn't complete - and on 64bits it's 464Kb of tables alone. Needless to say I'm worried about these sizes getting too large given that D is pretty much statically linked ATM.
It didn't get lost. I saw it. I just haven't had the chance to review it yet. :) [...]
 Let me make it more explicit.
 
 I'm looking for a review manager and anybody willing to revive the
 review process instead of venting steam on proper property (pun
 intended) design and seeking a value in requiring parens on no-arg
 call (or proving otherwise).
[...] Yeah I've basically resorted to thread-deleting the entire property thread along with its several unending sibling threads. It's not so much that I don't care about it, as that it's just gotten too long-winded and tiring. I'm ready to throw up my hands and let it all go down the pipes. I don't think I've the time/energy to be a review manager, but I *will* try to get to reviewing the code again sometime soon. IMNSHO, getting the new std.uni into Phobos is *far* more important (and far more profitable!) than the mountain out of molehill that is the current property discussion. T -- I'm still trying to find a pun for "punishment"...
Jan 31 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
31-Jan-2013 23:48, H. S. Teoh пишет:
 On Thu, Jan 31, 2013 at 11:27:57PM +0400, Dmitry Olshansky wrote:
 30-Jan-2013 01:52, Dmitry Olshansky пишет:
 Recap:
 During a couple of rounds of the informal review new std.uni had its
 docs happily destroyed, and later re-written based on the feedback.
[snip]
 - Squeezed extra 31Kb slack from object-file size (32 bits, more on
 64).  Now all of the packed tables occupy around 350Kb (32bits) and
 If you happen to know some tricks to reduce object file size (and in
 turn the executable size), please chime in.
My post got lost in the ether apparently. And it even wasn't complete - and on 64bits it's 464Kb of tables alone. Needless to say I'm worried about these sizes getting too large given that D is pretty much statically linked ATM.
It didn't get lost. I saw it. I just haven't had the chance to review it yet. :)
Great, I think I was spoiled by the great speed of the previous destructive review. I guess no news is good news :)
 [...]
 Let me make it more explicit.

 I'm looking for a review manager and anybody willing to revive the
 review process instead of venting steam on proper property (pun
 intended) design and seeking a value in requiring parens on no-arg
 call (or proving otherwise).
[...] Yeah I've basically resorted to thread-deleting the entire property thread along with its several unending sibling threads. It's not so much that I don't care about it, as that it's just gotten too long-winded and tiring. I'm ready to throw up my hands and let it all go down the pipes. I don't think I've the time/energy to be a review manager, but I *will* try to get to reviewing the code again sometime soon. IMNSHO, getting the new std.uni into Phobos is *far* more important (and far more profitable!) than the mountain out of molehill that is the current property discussion. T
-- Dmitry Olshansky
Feb 02 2013
prev sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 31 January 2013 at 19:27:59 UTC, Dmitry Olshansky 
wrote:
 I'm looking for a review manager and anybody willing to revive 
 the review process instead of venting steam on proper property 
 (pun intended) design and seeking a value in requiring parens 
 on no-arg call (or proving otherwise).
If nobody else steps up in the next few days, I'll do it. But I really hope somebody beats me to it, as I'd rather focus completely on getting a new 2.061-based LDC release out. David
Jan 31 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 30, 2013 at 01:52:20AM +0400, Dmitry Olshansky wrote:
 Recap:
 During a couple of rounds of the informal review new std.uni had its
 docs happily destroyed, and later re-written based on the feedback.
 
 Notable changes:
 
 - Fixed a couple of latent bugs (ouch!)
 
 - unicode.xyz helper was redesigned to have a clear path for
 extension to properties other then binary ones. For instance to get
 all of code points with hangul syllable type L (leading Jamo):
 
 auto leadingJamo = unicode.hangulSyllableType("L");
 
 - Squeezed extra 31Kb slack from object-file size (32 bits, more on
 64). Now all of the packed tables occupy around 350Kb (32bits) and
 If you happen to know some tricks to reduce object file size (and in
 turn the executable size), please chime in.
 
 Code & benchmark: https://github.com/blackwhale/gsoc-bench-2012
 
 Docs: http://blackwhale.github.com/phobos/uni.html
 (looks far better without the JS jump-table)
 
 It's a standalone module at the moment. To use in place of current
 std.uni replace 'std.uni'->'uni' in your programs and compare the
 results. Make sure that both uni and unicode_tables modules are
 linked in, rdmd can take care of this dependency.
 
 P.S. Time to go for the formal review?
[...] Alright, I decided to just jump in and re-review std.uni. I *really* want to see this in Phobos, the sooner the better. Here are some comments: - In the first part of the docs, Terminology section, under "Code unit": I think you mistyped a ddoc macro, it should be ($(D char)) instead of (($D char)). - lineSep, paraSep: are these fixed values? It would be nice to indicate what their values are. - UnicodeDecomposition: it would be nice to document the values in this enum. - normalize(): I think your code example has a duplicated line (NFKC example appears twice). - allowedIn(): How about an example where a character is *not* allowed in a normalization form? - InversionList.opBinary: I still prefer ^ instead of ~ for symmetric difference. In D, ~ means "append", and it's very confusing when x~y means symmetric difference instead of append. - unicode.opDispatch: it would be nice to provide links to official Unicode documentation that lists all blocks/scripts, as a reference. - combiningClass: maybe provide a link to official Unicode docs that list combining class values? OK, a lot of this is just nitpicks... but overall, this new std.uni looks very good. Looking forward to it being merged into Phobos! T -- Marketing: the art of convincing people to pay for what they didn't need before which you can't deliver after.
Feb 23 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
23-Feb-2013 21:14, H. S. Teoh пишет:
 P.S. Time to go for the formal review?
[...] Alright, I decided to just jump in and re-review std.uni. I *really* want to see this in Phobos, the sooner the better.
Great. Sorry, I had to put your comments on the back-burner, and then I'd found out that std.uni no longer compiles. New release darn it... Turned out that some screws were tightened up in the compiler and some meaningless qualifiers are no longer accepted. That plus some vague shit with apparently obligatory property on save() for isForwardRange trait (wtf?). Phh... OK, now let's go over these.
 Here are some comments:

 - In the first part of the docs, Terminology section, under "Code unit":
    I think you mistyped a ddoc macro, it should be ($(D char)) instead of
    (($D char)).
Fixed.
 - lineSep, paraSep: are these fixed values? It would be nice to indicate
    what their values are.
Yup, a carry-over from the old std.uni. Documented.
 - UnicodeDecomposition: it would be nice to document the values in this
    enum.

 - normalize(): I think your code example has a duplicated line (NFKC
    example appears twice).
Fixed.
 - allowedIn(): How about an example where a character is *not* allowed
    in a normalization form?
These are typically hard to recognize visually but I'll try :)
 - InversionList.opBinary: I still prefer ^ instead of ~ for symmetric
    difference. In D, ~ means "append", and it's very confusing when x~y
    means symmetric difference instead of append.
I need more then a single opinion on this matter. Yes, I don't quite like '~' but it's the symbol used in std.regex patterns and to make matters worse '^' means something completely different there.
 - unicode.opDispatch: it would be nice to provide links to official
    Unicode documentation that lists all blocks/scripts, as a reference.
I provided one, but it's probably not listed where it should be, see first paragraphs that outline the stuff in this module. I'm thinking I'd better compose a small table of _guaranteed_ properties. This would allow me to safely cleanup the ridiculous sets later on. Since the stuff was extracted from Unicode data files, even I'm not sure which sets are there exactly :) The guaranteed ones are Scripts, Blocks, General Category and few nice sets like ASCII (plus HangulSyllableType, of course!).
 - combiningClass: maybe provide a link to official Unicode docs that
    list combining class values?
If there was one good link... I might make an enum with symbolic names for the ones that are in use and have meaning.
 OK, a lot of this is just nitpicks... but overall, this new std.uni
 looks very good. Looking forward to it being merged into Phobos!
And for that to happen somebody has to put on the review manager's robe and do the ceremony (hint) :) I the meantime I need to present it also as a pull request to help reviewing the code. -- Dmitry Olshansky
Feb 25 2013
prev sibling next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
would it make sense to incoporate test from the ICU testsuite - there 
are api tests and many data tests around

some can find the tests in the current release under

icu4c-50_1_2-src\icu\source\test

Am 29.01.2013 22:52, schrieb Dmitry Olshansky:
 Recap:
 During a couple of rounds of the informal review new std.uni had its
 docs happily destroyed, and later re-written based on the feedback.

 Notable changes:

 - Fixed a couple of latent bugs (ouch!)

 - unicode.xyz helper was redesigned to have a clear path for extension
 to properties other then binary ones. For instance to get all of code
 points with hangul syllable type L (leading Jamo):

 auto leadingJamo = unicode.hangulSyllableType("L");

 - Squeezed extra 31Kb slack from object-file size (32 bits, more on 64).
 Now all of the packed tables occupy around 350Kb (32bits) and
 If you happen to know some tricks to reduce object file size (and in
 turn the executable size), please chime in.

 Code & benchmark: https://github.com/blackwhale/gsoc-bench-2012

 Docs: http://blackwhale.github.com/phobos/uni.html
 (looks far better without the JS jump-table)

 It's a standalone module at the moment. To use in place of current
 std.uni replace 'std.uni'->'uni' in your programs and compare the
 results. Make sure that both uni and unicode_tables modules are linked
 in, rdmd can take care of this dependency.

 P.S. Time to go for the formal review?

 P.P.S. Got to catch some sleep ...
Feb 24 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
24-Feb-2013 12:32, dennis luehring пишет:
 would it make sense to incoporate test from the ICU testsuite - there
 are api tests and many data tests around
For key algorithms I'm using consortium's test data files + plus running random generated stress-tests against ICU. It might make sense to incorporate some of their tests but I'm wondering if it'll end up only as a difference in the API. That being said tests are already unwieldy and largely run as a separate programs depending on the said data files. unittests there are mostly sanity and self-agreement between components kind of tests.
 some can find the tests in the current release under

 icu4c-50_1_2-src\icu\source\test
-- Dmitry Olshansky
Feb 25 2013
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 25.02.2013 19:31, schrieb Dmitry Olshansky:
 24-Feb-2013 12:32, dennis luehring пишет:
 would it make sense to incoporate test from the ICU testsuite - there
 are api tests and many data tests around
For key algorithms I'm using consortium's test data files + plus running random generated stress-tests against ICU. It might make sense to incorporate some of their tests but I'm wondering if it'll end up only as a difference in the API.
are doing any benchmark tests again other implementations like ICU or Qt's QString, etc.? are there any operations that are slower then other implementations?
Feb 26 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
26-Feb-2013 12:27, dennis luehring пишет:
 Am 25.02.2013 19:31, schrieb Dmitry Olshansky:
 24-Feb-2013 12:32, dennis luehring пОшет:
 would it make sense to incoporate test from the ICU testsuite - there
 are api tests and many data tests around
For key algorithms I'm using consortium's test data files + plus running random generated stress-tests against ICU. It might make sense to incorporate some of their tests but I'm wondering if it'll end up only as a difference in the API.
are doing any benchmark tests again other implementations like ICU or Qt's QString, etc.?
Not all that much but this is on todo list. If anything it takes a fair bit of time to install the lib, decipher the API and see how to make it do things like normalization of UTF32 buffer in memory. The 2 major moments I was concerned with are: a) all old things should not get slower then std.uni (in fact they are many times faster) b) correct (as in spec) and in line with others - currently only ICU but that's the defacto standard
 are there any operations that are slower then other implementations?
Till the data is available. It would be of tremendous help if you can test it against some library that you are comfortable with. -- Dmitry Olshansky
Feb 26 2013
prev sibling parent reply "tn" <no email.com> writes:
Hi. Just a couple stupid questions:

* What is the relation between std.uni and std.utf? Why is two 
modules needed? Seems confusing to me. Shouldn't these be 
combined? If not, then please explain the the distinction in the 
beginning of the module documentation.

* Shouldn't the module be renamed to std.unicode? We do not have 
std.arr, std.alg or std.cont either. To me, it is not at all 
obvious what std.uni contains based on the module name.
Feb 25 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
25-Feb-2013 22:08, tn пишет:
 Hi. Just a couple stupid questions:

 * What is the relation between std.uni and std.utf? Why is two modules
 needed? Seems confusing to me. Shouldn't these be combined? If not, then
 please explain the the distinction in the beginning of the module
 documentation.
std.uni was the C's "ctype" of the Unicode. Except it failed to deliver even this starting with about Unicode 5.1. std.utf is all about encoding/decoding UTF-8, UTF-16. If I were designing it from scratch (and what the hell I might one day have to) I'd put these into std.encoding or even std.encoding.utf. I'd probably put a small note that basic encoding is both: a) built-in into the language (foreach) b) to be found in std.utf
 * Shouldn't the module be renamed to std.unicode?
Good idea. But part of the reason was fixing the existing std.uni to: a) let it work in Unicode 6.1 world (and even 6.2 as of now) b) make it faster when dealing with Unicode code points in all of the isAlpha etc. functions. c) add a bunch of new cool tools for Unicode Basically the API is a superset of the existing one. I didn't want to change the name.
 We do not have
 std.arr, std.alg or std.cont either. To me, it is not at all obvious
 what std.uni contains based on the module name.
What can I say Phobos is an example of software evolution ;) -- Dmitry Olshansky
Feb 25 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-25 19:21, Dmitry Olshansky wrote:

 What can I say Phobos is an example of software evolution ;)
Is the new std.uni completely backwards compatible with the old one. Otherwise we have the same problem as with std.process. But in this case we have another name that is actually better. I'm having some problem understanding the obsession in shortening names, even when the full name isn't particular long. -- /Jacob Carlborg
Feb 25 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, February 26, 2013 08:20:54 Jacob Carlborg wrote:
 On 2013-02-25 19:21, Dmitry Olshansky wrote:
 What can I say Phobos is an example of software evolution ;)
Is the new std.uni completely backwards compatible with the old one. Otherwise we have the same problem as with std.process. But in this case we have another name that is actually better. I'm having some problem understanding the obsession in shortening names, even when the full name isn't particular long.
Well, it can get pretty bad with module names when you're forced to give the full import path. For instance, std.string, std.ascii, and std.uni all have toLower, and std.unicode.toLower is definitely longer than std.uni.toLower. In general, names should be as long as they need to be in order to be properly clear and descriptive but no longer. Making names too short makes code harder to read and understand, and making them too long makes it harder to fit as much in a line of code without it getting too long. That being said, std.unicode is probably a better name than std.uni, but at this point, it's better to maintain backwards compatibility than to rename it. If we need to rename it because of changes in the API, then going with std.unicode makes sense, but if the necessary changes are backwards compatible, then we should avoid renaming it and thus avoid breaking code. - Jonathan M Davis
Feb 25 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-26 08:34, Jonathan M Davis wrote:

 Well, it can get pretty bad with module names when you're forced to give the
 full import path. For instance, std.string, std.ascii, and std.uni all have
 toLower, and std.unicode.toLower is definitely longer than std.uni.toLower.
If you think that "std.unicode.toLower" is too long then create an alias for it. BTW, I don't think it's fair to use the fully qualified name when comparing. Then we can never have a nested package hierarchy in Phobos or we will get names looking like: std.a.b.c.d
 In general, names should be as long as they need to be in order to be properly
 clear and descriptive but no longer. Making names too short makes code harder
 to read and understand, and making them too long makes it harder to fit as much
 in a line of code without it getting too long.

 That being said, std.unicode is probably a better name than std.uni, but at
 this point, it's better to maintain backwards compatibility than to rename it.
 If we need to rename it because of changes in the API, then going with
 std.unicode makes sense, but if the necessary changes are backwards
 compatible, then we should avoid renaming it and thus avoid breaking code.
-- /Jacob Carlborg
Feb 25 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, February 26, 2013 08:40:02 Jacob Carlborg wrote:
 On 2013-02-26 08:34, Jonathan M Davis wrote:
 Well, it can get pretty bad with module names when you're forced to give
 the full import path. For instance, std.string, std.ascii, and std.uni
 all have toLower, and std.unicode.toLower is definitely longer than
 std.uni.toLower.
If you think that "std.unicode.toLower" is too long then create an alias for it. BTW, I don't think it's fair to use the fully qualified name when comparing. Then we can never have a nested package hierarchy in Phobos or we will get names looking like: std.a.b.c.d
It's still something that needs to be considered. Having overly long names _will_ create problems, as will overly short names. A balance is needed. Fully qualified names just show one of the costs to longer names. Picking good names is a bit of an art. Going the C route of overly short names is a mistake as is going the Java route of overly descriptive ones. In the case of std.uni vs std.unicode, I probably would agree that std.unicode is better, because it's more destriptive, whereas std.uni is arguably not descriptive enough as nice as its length may be. So, if we were starting from scratch, std.unicode would make more sense. However, as we're not starting from scratch, and switching to std.unicode would break a lot of code, it's not worth switching to std.unicode just for a more descriptive name. It would be a good choice if we had to change the name for other reasons (e.g. the API needed to be changed in a non-backwards-compatible manner), but improving the name isn't a good enough reason. - Jonathan M Davis
Feb 25 2013
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
26-Feb-2013 11:20, Jacob Carlborg пишет:
 On 2013-02-25 19:21, Dmitry Olshansky wrote:

 What can I say Phobos is an example of software evolution ;)
Is the new std.uni completely backwards compatible with the old one. Otherwise we have the same problem as with std.process. But in this case we have another name that is actually better.
It is backwards compatible and was created to be a drop in replacement as one of its requirements. In any case the API of std.uni is small and simple enough to keep it as is.
 I'm having some problem understanding the obsession in shortening names,
 even when the full name isn't particular long.
Let's not go there. And uni is not obsession at all. POSIX 'O_CREAT' is. -- Dmitry Olshansky
Feb 26 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-26 17:51, Dmitry Olshansky wrote:

 Let's not go there. And uni is not obsession at all. POSIX 'O_CREAT' is.
The obsession is that there's quite a lot of shortened names in D. -- /Jacob Carlborg
Feb 26 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, February 26, 2013 20:34:13 Jacob Carlborg wrote:
 On 2013-02-26 17:51, Dmitry Olshansky wrote:
 Let's not go there. And uni is not obsession at all. POSIX 'O_CREAT' is.
The obsession is that there's quite a lot of shortened names in D.
Really? There are a few (particularly older ones), but for the most part, I'd argue that that's not the case at all. In general, IMHO, Phobos does an excellent job of having function names that are reasonably descriptive and are of a reasonable length. And, if anything, we tend to err on the side of being too long (e.g. ElementEncodingType). - Jonathan M Davis
Feb 26 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-26 21:13, Jonathan M Davis wrote:

 Really? There are a few (particularly older ones), but for the most part, I'd
 argue that that's not the case at all. In general, IMHO, Phobos does an
 excellent job of having function names that are reasonably descriptive and are
 of a reasonable length. And, if anything, we tend to err on the side of being
 too long (e.g. ElementEncodingType).

 - Jonathan M Davis
These are just a couple: std.string icmp makeTrans succ abbrev std.array assocArray std.file isDir attrIsDir attrIsFile attrIsSymlink dirEntries std.uni lineSep paraSep std.datetime currTime Every member of the Month, DayOfWeek and Direction enums. fracSec -- /Jacob Carlborg
Feb 27 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, February 27, 2013 22:07:04 Jacob Carlborg wrote:
 On 2013-02-26 21:13, Jonathan M Davis wrote:
 Really? There are a few (particularly older ones), but for the most part,
 I'd argue that that's not the case at all. In general, IMHO, Phobos does
 an excellent job of having function names that are reasonably descriptive
 and are of a reasonable length. And, if anything, we tend to err on the
 side of being too long (e.g. ElementEncodingType).
 
 - Jonathan M Davis
These are just a couple: std.string icmp makeTrans succ abbrev std.array assocArray std.file isDir attrIsDir attrIsFile attrIsSymlink dirEntries std.uni lineSep paraSep std.datetime currTime Every member of the Month, DayOfWeek and Direction enums. fracSec
And in almost all cases, I see nothing to complain about here. Most of them are quite clear as they are. Making them longer would just make them longer to no real benefit IMHO, and it _would_ be adding a cost. You seem to think that abbreviations are bad, and I completely disagree. IMHO, a symbol name should be as long as it needs to be in order to be clear and no longer, and as long as an abbreviation is clear, then it's great to use it. But if you have problems with most of those names, then I think that it's pretty clear that we're just going to have to agree to disagree on this, because for the most part, I think that they're great as they are. - Jonathan M Davis
Feb 27 2013
parent reply "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Wednesday, 27 February 2013 at 23:17:42 UTC, Jonathan M Davis 
wrote:
 On Wednesday, February 27, 2013 22:07:04 Jacob Carlborg wrote:
 On 2013-02-26 21:13, Jonathan M Davis wrote:
 Really? There are a few (particularly older ones), but for 
 the most part,
 I'd argue that that's not the case at all. In general, IMHO, 
 Phobos does
 an excellent job of having function names that are 
 reasonably descriptive
 and are of a reasonable length. And, if anything, we tend to 
 err on the
 side of being too long (e.g. ElementEncodingType).
 
 - Jonathan M Davis
These are just a couple: std.datetime currTime Every member of the Month, DayOfWeek and Direction enums. fracSec
Would 'now' be even better than 'currTime'?
Feb 27 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, February 28, 2013 01:38:17 Zach the Mystic wrote:
 On Wednesday, 27 February 2013 at 23:17:42 UTC, Jonathan M Davis
 
 wrote:
 On Wednesday, February 27, 2013 22:07:04 Jacob Carlborg wrote:
 On 2013-02-26 21:13, Jonathan M Davis wrote:
 Really? There are a few (particularly older ones), but for
 the most part,
 I'd argue that that's not the case at all. In general, IMHO,
 Phobos does
 an excellent job of having function names that are
 reasonably descriptive
 and are of a reasonable length. And, if anything, we tend to
 err on the
 side of being too long (e.g. ElementEncodingType).
 
 - Jonathan M Davis
These are just a couple: std.datetime currTime Every member of the Month, DayOfWeek and Direction enums. fracSec
Would 'now' be even better than 'currTime'?
I don't think so (other than maybe due to the fact that it's shorter), though I know that some people would think so. But it never even occurred to me to call it that when I wrote it, and I don't think that anyone ever brought it up during the review process. Regardless, currTime works just fine, and even if now would have been better, it's not even vaguely worth it to rename it at this point. - Jonathan M Davis
Feb 27 2013
parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Thursday, 28 February 2013 at 01:04:00 UTC, Jonathan M Davis 
wrote:
 On Thursday, February 28, 2013 01:38:17 Zach the Mystic wrote:
 On Wednesday, 27 February 2013 at 23:17:42 UTC, Jonathan M 
 Davis
 
 wrote:
 On Wednesday, February 27, 2013 22:07:04 Jacob Carlborg 
 wrote:
 On 2013-02-26 21:13, Jonathan M Davis wrote:
 Really? There are a few (particularly older ones), but for
 the most part,
 I'd argue that that's not the case at all. In general, 
 IMHO,
 Phobos does
 an excellent job of having function names that are
 reasonably descriptive
 and are of a reasonable length. And, if anything, we tend 
 to
 err on the
 side of being too long (e.g. ElementEncodingType).
 
 - Jonathan M Davis
These are just a couple: std.datetime currTime Every member of the Month, DayOfWeek and Direction enums. fracSec
Would 'now' be even better than 'currTime'?
I don't think so (other than maybe due to the fact that it's shorter), though I know that some people would think so. But it never even occurred to me to call it that when I wrote it, and I don't think that anyone ever brought it up during the review process. Regardless, currTime works just fine, and even if now would have been better, it's not even vaguely worth it to rename it at this point. - Jonathan M Davis
Into my cryogenic idealistic freezer it goes!
Feb 27 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-28 01:38, Zach the Mystic wrote:

 Would 'now' be even better than 'currTime'?
I think so. -- /Jacob Carlborg
Feb 28 2013
parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Thursday, 28 February 2013 at 08:07:28 UTC, Jacob Carlborg 
wrote:
 On 2013-02-28 01:38, Zach the Mystic wrote:

 Would 'now' be even better than 'currTime'?
I think so.
Be careful what you say, or you might have to go into my cryogenic freezer as well!
Feb 28 2013