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