On 03/07/2012 11:30 PM, Jonathan M Davis wrote:
> On Wednesday, March 07, 2012 17:06:21 Nick Sabalausky wrote:
>> Ahh, yea I remember now. I'd argue (strongly) that if a symbol is
>> inaccessible than it should never conflict with a symbol that is accessible.
>> After all, is there really much more point to the "visible vs accessible"
>> distinction besides just being able to say "Symbol xxxx is private" instead
>> of "Unrecognzed symbol xxxx"?
>
> Well, truth be told, it should be possible for the compiler to still say that
> the symbol is private rather than that it's unrecognized. Just because it's
> hidden for overload resolution and the like doesn't mean that the compiler
> couldn't still recognize it as existing but inaccessible in cases where
> there's no other match. It _is_ probably easier to implement it with the
> "unrecognized symbol" behavior though.
>
> The only real downside that I can think of of making private symbols hidden is
> that it could cause issues when symbols are changed to or from private, but
> the way that overload sets are handled probably prevents that from being a
> real issue. It may break code, but I don't think that it would silently break
> code to change a symbol to or from private, which would be the real problem.
>
> - Jonathan M Davis

Yes, private symbols probably shouldn't be hidden completely. For example, private constructors convey special semantics. (their existence also removes the default constructor) But private symbols should never conflict with public symbols. Probably it is best to also disallow overloading private symbols against public symbols.

On Wednesday, 7 March 2012 at 21:39:39 UTC, Timon Gehr wrote:
> On 03/07/2012 09:04 PM, foobar wrote:
>> On Wednesday, 7 March 2012 at 10:08:53 UTC, Timon Gehr wrote:
>>> On 03/06/2012 10:30 PM, deadalnix wrote:
>>>>
>>>> auto helps too.
>>>
>>> This remark was explicitly about _Java_ code style.
>>
>> Wrong. This is an issue with the *language*, NOT the naming convention.
>
> It is hard to imagine how it could be concluded that this is not what the post has expressed.

Come on, do we really need to discuss the difference between a programming language and its coding conventions?
The fact that Java has flaws *as a language* is completely orthogonal to the fact that it has an excellent coding convention which can also be used with other languages such as D.

One of the reasons for Java's success is its code style despite being a simplistic language. It might be painful to write "duration" instead of "dur" when working on your own pet project but it's in a different story when dealing with large enterprise systems. IMO D will not catch on in a larger setting (in the enterprise) as long as it refuses to grow up and keeps it advocating its 1337 hacker attitude.

On 03/08/2012 01:08 AM, foobar wrote:
> On Wednesday, 7 March 2012 at 21:39:39 UTC, Timon Gehr wrote:
>> On 03/07/2012 09:04 PM, foobar wrote:
>>> On Wednesday, 7 March 2012 at 10:08:53 UTC, Timon Gehr wrote:
>>>> On 03/06/2012 10:30 PM, deadalnix wrote:
>>>>>
>>>>> auto helps too.
>>>>
>>>> This remark was explicitly about _Java_ code style.
>>>
>>> Wrong. This is an issue with the *language*, NOT the naming convention.
>>
>> It is hard to imagine how it could be concluded that this is not what
>> the post has expressed.
>
> Come on, do we really need to discuss the difference between a
> programming language and its coding conventions?
> The fact that Java has flaws *as a language* is completely orthogonal to
> the fact that it has an excellent coding convention which can also be
> used with other languages such as D.
>
> One of the reasons for Java's success is its code style despite being a
> simplistic language. It might be painful to write "duration" instead of
> "dur" when working on your own pet project but it's in a different story
> when dealing with large enterprise systems. IMO D will not catch on in a
> larger setting (in the enterprise) as long as it refuses to grow up and
> keeps it advocating its 1337 hacker attitude.
>

To make this clear, we agree on the relevant issues. There obviously has been a misunderstanding, and it does not make sense to argue about it.

On 07/03/2012 19:03, H. S. Teoh wrote:
<snip>
> clr == common language runtime
> col == polysemous word meaning anything from column to color to collect to colon.
<snip>

When I went to school, the _word_ "col" meant a mountain pass, not any of those things.

Stewart.

On 07/03/2012 08:10, Jacob Carlborg wrote:
<snip>
> Yeah, Clock.now() would be good and Data.today() as well.

My utility library has, for consistency, DateValue.now, TimeValue.now and DateTime.now.

Stewart.

On Wednesday, 7 March 2012 at 18:39:41 UTC, Nick Sabalausky wrote:
> "Adam D. Ruppe" <destructionator@gmail.com> wrote in message
> news:sgmfyzmrfygshlmfqsdj@forum.dlang.org...
>> On Tuesday, 6 March 2012 at 20:20:47 UTC, Derek wrote:
>>> Should we use American or English spelling? Color verses Colour, for example?
>>
>> I can go either way. I lean toward English spelling
>> though, simply because America is the exceptional
>> country (in the world and on the newsgroup too) in
>> this regard.
>>
>
> British English may be the more "official" English, with American English as
> a mere variation, but AIUI, the "de facto international language" is
> American English, not British English, as a result of the US being a
> long-time major economic superpower (for better or worse). England used to
> be a major superpower, but that was centuries ago, and from what I can tell,
> American English seems to be the preferred "de facto standard" English now.
>
>> But, either option is better than "Clr" or "Col".
>
> "clr" is the verb "clear" and "col" is "column" :)

In my programs I use British English because that's what I use, and anything else looks 'wrong' to me. If the API is particularly public, I usually provide an alias. Then again, I'm just a colonial hick, so what would I know? :P

On 3/6/12 9:25 PM, Jonathan M Davis wrote:
> On Tuesday, March 06, 2012 20:58:52 Ary Manzana wrote:
>> On 3/6/12 8:43 PM, Jonathan M Davis wrote:
>>> On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:
>>>> writeln(time.toISOExtendedString()); // bzzt, wrong, but this
>>>> used to work!
>>>
>>> Yes, and it was quickly changed to toISOExtString, because
>>> toISOExtendedString is painfully long. toISOExtString is bad enough, but
>>> you can't really make it any shorter without making the name
>>> uninformative.
>>>
>>>> Nope, apparently, I meant "dur". Ridiculous.
>>>
>>> A Duration needs to be constructed with a template, and
>>> duration!"hours"(13), duration!"seconds"(44), etc. is painfully long when
>>> used in expressions. So, it was shortened to dur. I don't know of any
>>> other abbreviation which would make sense.
>>
>> Painfully long?
>>
>> How much time does it take you to type 5 more chars? How much time does
>> it take you to understand "dur" when you read it instead of "duration"?
>>
>>> I agree with H.S. Teoh in that abbreviations should be meaniful and
>>> consistent but that they _should_ be used where applicable. Code becomes
>>> painfully long otherwise - especially when chaining function calls and
>>> the like.
>>
>> Code becomes painfully long when you write lots of lines, not when you
>> write long lines. Specially when you write lots of boilerplate lines.
>
> You don't write much code in functional style, do you?

Here's something I wrote today:

parent_ids = results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact
Hash[Site.find(parent_ids).map{|x| [x.id, x]}]

Or I could have written:

Hash[
  Site.find(
    results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact
  ).map{|x| [x.id, x]}
]

No abbreviation at all, many function calls, functional style in the middle (the couple of "map").

In Ruby it's not such a big problem to have descriptive names.

I guess in D it would be longer because of all the template invocation, the argument types, etc. I just guess it, I'm not sure.


If you chain functions
> much, then long names very quickly result in long lines, which makes the code
> harder to read, and can quickly lead to expressions having to be multiple
> lines, simply because the symbol names involved were overly verbose.
>
> While, I grant you that duration!"minutes"(5) might be more immediately clear
> than dur!"minutes"(5) is, I don't buy that it makes all that much of a
> differences. You're not going to mistake dur for anything else even if it
> doesn't immediately occur to you that it's an abbreviation for duration, and
> the units make it very clear that it's related to time. And since dur is
> something that's likely to be commonly used, it will very quick and easy to
> remember what it is.

The problem is not mistaking it with something else. The problem is when you want to write it. In Ruby my mind works like this:

Mind: "How would I get a span for 5 seconds?"
Mind: "Let's try 5.seconds"
Mind: "Wow, it works!"

I'm trying to remember cases when I just wrote what my mind thought it was correct and I was *so* surprised it worked out of the box in Ruby. Like writing array.last, and get it to work, instead of array[array.length - 1]. But in D, from the docs (http://dlang.org/arrays.html )

bar[$-1] // retrieves last element of the array

I read: bar dollar minus one wait what??

Now, in D I try:

5.seconds

and it doesn't work. I have to write this very unintuitive:

dur!"minutes"(5)

Was it really necessary to implement it that way?

Again, the problem is not understanding the meaning, the problem is guessing what you have to write and get it right the first time.

On Wednesday, 7 March 2012 at 19:12:25 UTC, H. S. Teoh wrote:
> Supporting stuff like 5.hours will introduce additional complications to
> D's lexical structure, though. The lexer will have to understand it as
> (int:5)(.)(ident:hours) rather than (float:5.)(ident:hours). And then if
> you actually *wanted* a float, you'd have another ambiguity: 5..hours
> could mean (float:5.)(.)(ident:hours) or (int:5)(..)(hours). And
> 5.0.hours just looks... weird.
>
>
> T

Actually, Kenji's pull request for UFCS already takes care of this. Things like 5. aren't allowed, nor is 5.f; a number has to follow the decimal. So 5.f would invoke UFCS function f with the integer 5. I believe this change is already merged, though the rest of the UFCS pull request isn't unfortunately.

On Thu, 08 Mar 2012 01:00:48 +0100, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 03/07/2012 11:30 PM, Jonathan M Davis wrote:
>> On Wednesday, March 07, 2012 17:06:21 Nick Sabalausky wrote:
>>> Ahh, yea I remember now. I'd argue (strongly) that if a symbol is
>>> inaccessible than it should never conflict with a symbol that is accessible.
>>> After all, is there really much more point to the "visible vs accessible"
>>> distinction besides just being able to say "Symbol xxxx is private" instead
>>> of "Unrecognzed symbol xxxx"?
>>
>> Well, truth be told, it should be possible for the compiler to still say that
>> the symbol is private rather than that it's unrecognized. Just because it's
>> hidden for overload resolution and the like doesn't mean that the compiler
>> couldn't still recognize it as existing but inaccessible in cases where
>> there's no other match. It _is_ probably easier to implement it with the
>> "unrecognized symbol" behavior though.
Private symbols can be proposed during the spell correction lookup.

>>
>> The only real downside that I can think of of making private symbols hidden is
>> that it could cause issues when symbols are changed to or from private, but
>> the way that overload sets are handled probably prevents that from being a
>> real issue. It may break code, but I don't think that it would silently break
>> code to change a symbol to or from private, which would be the real problem.
>>
>> - Jonathan M Davis
>
> Yes, private symbols probably shouldn't be hidden completely. For example, private constructors convey special semantics. (their existence also removes the default constructor) But private symbols should never conflict with public symbols. Probably it is best to also disallow overloading private symbols against public symbols.
It doesn't work out if you want to overload private/public constructors.

https://github.com/D-Programming-Language/dmd/pull/739

On Thursday, March 08, 2012 01:22:42 Stewart Gordon wrote:
> On 07/03/2012 08:10, Jacob Carlborg wrote:
> <snip>
> 
> > Yeah, Clock.now() would be good and Data.today() as well.
> 
> My utility library has, for consistency, DateValue.now, TimeValue.now and DateTime.now.

I specically avoided giving a way to get the time with any type other than SysTime (and TickDuration for using a monotonic clock), because I believe that it leads to incorrect behavior. Any time that you're dealing with the system clock, you should be dealing with SysTime. Date, TimeOfDay, and DateTime are for when you need the date and/or time but don't care about what absolute time it's associated with in the real world. Treating DateTime as corresponding to a specific point in time is just going to cause problems, because it has no time zone. It could correspond to over 24 different times. By restricting getting the time to SysTime, it encourages the writing of correct code.

- Jonathan M Davis