"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.180.1331149159.4860.digitalmars-d@puremagic.com...
> On Tuesday, March 06, 2012 21:56:38 H. S. Teoh wrote:
>> On Tue, Mar 06, 2012 at 07:48:37PM -0800, Jonathan M Davis wrote:
>> > On Tuesday, March 06, 2012 19:35:29 Andrei Alexandrescu wrote:
>> > > In fact there is no such thing as a top level in D. (I was quite surprised to learn that a few years ago, and found it quite brilliant of Walter.)
>> >
>> > True, but if names conflict, you then have to worry about using the full import paths for symbols, which can get annoying.
>>
>> [...]
>>
>> I thought that's what module aliases were for.
>
> They can help, but thanks to the fact that they impact any other modules
> that
> import that module, they're often unacceptable.
>

That's just an implementation bug, though, isn't it? And wasn't it recently fixed?

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.

On Wednesday, March 07, 2012 15:34:44 Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.180.1331149159.4860.digitalmars-d@puremagic.com...
> 
> > On Tuesday, March 06, 2012 21:56:38 H. S. Teoh wrote:
> >> On Tue, Mar 06, 2012 at 07:48:37PM -0800, Jonathan M Davis wrote:
> >> > On Tuesday, March 06, 2012 19:35:29 Andrei Alexandrescu wrote:
> >> > > In fact there is no such thing as a top level in D. (I was quite surprised to learn that a few years ago, and found it quite brilliant of Walter.)
> >> > 
> >> > True, but if names conflict, you then have to worry about using the full import paths for symbols, which can get annoying.
> >> 
> >> [...]
> >> 
> >> I thought that's what module aliases were for.
> > 
> > They can help, but thanks to the fact that they impact any other modules
> > that
> > import that module, they're often unacceptable.
> 
> That's just an implementation bug, though, isn't it? And wasn't it recently fixed?

It's a design issue. Yes, the bug that private didn't affect aliases was fixed, but private does _not_ hide symbols. It only makes them inaccessible. So, for instance, if std.datetime were to alias std.string.indexOf to indexOf, then every module which imports both std.algorithm and std.datetime would then have to either alias std.algorithm.indexOf themselves or use the full import path. So, as it stands, private aliases are pretty much useless. It's just like how private functions can affect function overloading in spite of the fact that other modules can't use them.

This completely follows how private is designed. So, it's not a bug. But there are definitely arguments for changing how private works (e.g. the fact that you can't really alias stuff within a module without affecting other modules). The trick is convincing Walter to change it.

- Jonathan M Davis

On 03/07/2012 10:47 PM, Jonathan M Davis wrote:
> On Wednesday, March 07, 2012 15:34:44 Nick Sabalausky wrote:
>> "Jonathan M Davis"<jmdavisProg@gmx.com>  wrote in message
>> news:mailman.180.1331149159.4860.digitalmars-d@puremagic.com...
>>
>>> On Tuesday, March 06, 2012 21:56:38 H. S. Teoh wrote:
>>>> On Tue, Mar 06, 2012 at 07:48:37PM -0800, Jonathan M Davis wrote:
>>>>> On Tuesday, March 06, 2012 19:35:29 Andrei Alexandrescu wrote:
>>>>>> In fact there is no such thing as a top level in D. (I was quite
>>>>>> surprised to learn that a few years ago, and found it quite
>>>>>> brilliant of Walter.)
>>>>>
>>>>> True, but if names conflict, you then have to worry about using the
>>>>> full import paths for symbols, which can get annoying.
>>>>
>>>> [...]
>>>>
>>>> I thought that's what module aliases were for.
>>>
>>> They can help, but thanks to the fact that they impact any other modules
>>> that
>>> import that module, they're often unacceptable.
>>
>> That's just an implementation bug, though, isn't it? And wasn't it recently
>> fixed?
>
> It's a design issue. Yes, the bug that private didn't affect aliases was fixed,
> but private does _not_ hide symbols. It only makes them inaccessible. So, for
> instance, if std.datetime were to alias std.string.indexOf to indexOf, then
> every module which imports both std.algorithm and std.datetime would then have
> to either alias std.algorithm.indexOf themselves or use the full import path.
> So, as it stands, private aliases are pretty much useless. It's just like how
> private functions can affect function overloading in spite of the fact that
> other modules can't use them.
>
> This completely follows how private is designed. So, it's not a bug. But there
> are definitely arguments for changing how private works (e.g. the fact that you
> can't really alias stuff within a module without affecting other modules). The
> trick is convincing Walter to change it.
>
> - Jonathan M Davis

There is absolutely no remotely valid argument against changing the behavior that does not involve a discussion of the compiler internals.

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.175.1331147548.4860.digitalmars-d@puremagic.com...
> On Wed, Mar 07, 2012 at 01:50:03PM -0500, Nick Sabalausky wrote:
>> Course, I can still live with just 'alias dur!"years" years;..etc...'.
>> The *main* thing is that we can just do "hours(5)"...(or heck, once
>> UFCS finally gets fixed: "5.hours")
> [...]
>
> Hooray! Ruby syntax FTW!
>
> Tangential comment:
>
> Before I discovered D, Ruby was among the top candidates in my list of programming languages close to my ideals. Once D pulls off UFCS, it will trump Ruby in so many more ways... such as being able to effectively extend class methods just by declaring module-level functions of the form:
>
> retType func(classname obj, ...);
>
> (which I believe is already (somewhat?) supported). Among many other
> things.
>

I'm not really much of a ruby fan, except in comparison to python (I think ruby's whole "It's like English, just write it like you'd expect it to be written" thing is both untrue and misguided). But yea, UFCS is awesome (erm..."will be" awesome...eventually...I hope...).

> 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.
>

That "5."/".5" float syntax need to die anyway. It's just pointless and gets in the way of things that *aren't* pointless like UFCS.

I agree that "5.0.hours" looks a little weird, but meh, it's good enough and there's no fundamental problem with it (and it's a hell of a lot better than "5. .hours"). And you can just do "(5.0).hours" if you really want.

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.186.1331156894.4860.digitalmars-d@puremagic.com...
> On Wednesday, March 07, 2012 15:34:44 Nick Sabalausky wrote:
>> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.180.1331149159.4860.digitalmars-d@puremagic.com...
>>
>> > On Tuesday, March 06, 2012 21:56:38 H. S. Teoh wrote:
>> >> On Tue, Mar 06, 2012 at 07:48:37PM -0800, Jonathan M Davis wrote:
>> >> >
>> >> > True, but if names conflict, you then have to worry about using the full import paths for symbols, which can get annoying.
>> >>
>> >> [...]
>> >>
>> >> I thought that's what module aliases were for.
>> >
>> > They can help, but thanks to the fact that they impact any other
>> > modules
>> > that
>> > import that module, they're often unacceptable.
>>
>> That's just an implementation bug, though, isn't it? And wasn't it
>> recently
>> fixed?
>
> It's a design issue. Yes, the bug that private didn't affect aliases was
> fixed,
> but private does _not_ hide symbols. It only makes them inaccessible. So,
> for
> instance, if std.datetime were to alias std.string.indexOf to indexOf,
> then
> every module which imports both std.algorithm and std.datetime would then
> have
> to either alias std.algorithm.indexOf themselves or use the full import
> path.
> So, as it stands, private aliases are pretty much useless.

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"?

On Wed, 07 Mar 2012 10:25:32 -0500, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Wed, 07 Mar 2012 08:47:48 -0500, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>
>> I'll see if I can do a pull request.
>
> Almost done, need to test:
>
> https://github.com/schveiguy/druntime/commit/cf9d1ba4f5498c447d91497cb5edbd735d2b4c7e
>
> Actually cleans up a lot of the template constraints too...

https://github.com/D-Programming-Language/druntime/pull/173

https://github.com/D-Programming-Language/phobos/pull/483

-Steve

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

On 06/03/2012 16:38, Adam D. Ruppe wrote:
> One of the stumbling blocks on using std.datetime is how
> many bizarre abbreviations it has.
>
> auto time = Clock.currentTime(); // bzzt, wrong
>
> if(time - something > duration!"hours"(4)) // bzzt, wrong
>
> writeln(time.toISOExtendedString()); // bzzt, wrong, but this used to work!
<snip>

The mention of this one reminds me of another issue: capitalisation consistency.  It would be nice to standardise whether acronyms/initialisms occurring within names have just the first letter or all letters capitalised.  I'm thinking best is to treat them as words and therefore capitalise just the first letter.  Though I've been known to do otherwise in the past.

But it's confusing enough that there are still many functions in Phobos whose names are all lowercase when they should be camelCase.

The Java API is in a mess in this respect:
http://www.mindprod.com/jgloss/inconsistencies.html

We'd have no trouble avoiding this if only Phobos was designed to be free of such inconsistencies from its beginning.

Stewart.

On 6-3-2012 19:35, H. S. Teoh wrote:
> On Tue, Mar 06, 2012 at 07:13:47PM +0100, Alex Rønne Petersen wrote:

>> (Also, seriously, I think you're over-dramatizing the Java variable
>> naming thing; I rarely see names that are as bad as you claim...)
> [...]
>
> OK, I exaggerated a little. :-) But my point stands, that I find many of
> these names just way too long for my tastes. Like BufferedOutputStream.
> Or ByteArrayOutputStream.  Ugh. I mean, we're writing programs here, not
> essays. Why spell things out in full if we don't need to?

long time = System.currentTimeMillis();

I use a macro for that one :-)

Jos