On Thursday, 23 May 2013 at 08:49:15 UTC, Jonathan M Davis wrote:
I tried to fix all of the naming problems in Phobos previously
with the idea
that we'd fix them all and then move on, and I got a large
portion of them
fixed, but I didn't get them all, and I think that it's past
the time when it
On Friday, 24 May 2013 at 03:19:48 UTC, Marco Leise wrote:
Am Tue, 21 May 2013 20:34:02 +0200
schrieb Jacob Carlborg :
On 2013-05-21 19:53, Idan Arye wrote:
> The problem is that people that need Unicode stuff see
> `std.utf` and
> assume that all Unicode related stuff are there.
I never ca
Am Tue, 21 May 2013 19:12:12 +0200
schrieb Jacob Carlborg :
> On 2013-05-21 14:51, Dmitry Olshansky wrote:
> > The pitch by deadalnix:
> >
> > I strongly push into renaming it to std.unicode . As said in the other
> > thread : uni can be unicode, but also unique, union, unit, uniform,
> > unix, un
Am Tue, 21 May 2013 20:34:02 +0200
schrieb Jacob Carlborg :
> On 2013-05-21 19:53, Idan Arye wrote:
>
> > The problem is that people that need Unicode stuff see `std.utf` and
> > assume that all Unicode related stuff are there.
>
> I never can remember if I should look in std.utf or std.uni. Tha
On Thursday, 23 May 2013 at 08:46:02 UTC, Kagamin wrote:
On Tuesday, 21 May 2013 at 14:58:56 UTC, Peter Alexander wrote:
On Tuesday, 21 May 2013 at 14:32:46 UTC, Domain wrote:
http://docs.oracle.com/cd/B19306_01/server.102/b14200/functions204.htm
Sorry, but is a bit misleading. Yes, UNISTR, s
On 2013-05-23 12:21, Jonathan M Davis wrote:
Clearly, you don't agree, but we now
have minutes, seconds, etc. as aliases if you don't like dur.
Yeah, that's better.
--
/Jacob Carlborg
On Thursday, May 23, 2013 11:10:04 Jacob Carlborg wrote:
> On 2013-05-23 10:49, Jonathan M Davis wrote:
> > I understand why people want changes like this (and to some extent, I
> > agree), but I think that if they really wanted them, they should have
> > pushed for them and created pull requests f
On 2013-05-23 10:49, Jonathan M Davis wrote:
I understand why people want changes like this (and to some extent, I agree),
but I think that if they really wanted them, they should have pushed for them
and created pull requests for them long before now.
I don't see how a pull request will help.
On Tuesday, 21 May 2013 at 14:58:56 UTC, Peter Alexander wrote:
On Tuesday, 21 May 2013 at 14:32:46 UTC, Domain wrote:
I vote for std.unicode. Actually, I thought it was std.uri at
the first glance. And I never thought uni is short for unicode.
+1
I wondered what uni meant the first time I re
On Thursday, May 23, 2013 09:15:22 Jacob Carlborg wrote:
> > So, the question is whether it's worth making people change their code
> > sometime between when we make the change and when std.uni finally goes
> > away. And I don't think that making people change their code is worth it
> > regardless
On 2013-05-23 05:15, Jonathan M Davis wrote:
Every time that a library change is introduced it's done in a way that allows
the programmer time to migrate their code. I'm not aware of any case thus far
where we've purposefully changed library code in a manner which immediately
broke user code. We
On Thursday, 23 May 2013 at 05:32:13 UTC, deadalnix wrote:
On Thursday, 23 May 2013 at 03:15:44 UTC, Jonathan M Davis
wrote:
Every time that a library change is introduced it's done in a
way that allows
the programmer time to migrate their code. I'm not aware of
any case thus far
where we've pu
On Thursday, 23 May 2013 at 03:15:44 UTC, Jonathan M Davis wrote:
Every time that a library change is introduced it's done in a
way that allows
the programmer time to migrate their code. I'm not aware of any
case thus far
where we've purposefully changed library code in a manner which
immediate
On Thursday, May 23, 2013 03:42:56 deadalnix wrote:
> On Thursday, 23 May 2013 at 01:24:42 UTC, Idan Arye wrote:
> > Doing it while keeping `std.uni` would create a duplication in
> > both API and implementation, since `std.unicode` will contain
> > all the functionality of `std.uni`. Eventually `s
On Thursday, 23 May 2013 at 01:24:42 UTC, Idan Arye wrote:
Doing it while keeping `std.uni` would create a duplication in
both API and implementation, since `std.unicode` will contain
all the functionality of `std.uni`. Eventually `std.uni` would
have to be removed, because if Phobos would keep
On Thursday, 23 May 2013 at 00:43:04 UTC, deadalnix wrote:
On Wednesday, 22 May 2013 at 17:31:17 UTC, Jonathan M Davis
wrote:
On Tuesday, May 21, 2013 22:32:00 Brad Anderson wrote:
Would the public import people are suggesting not work for
maintaining backward compatibility?
Also, couldn't you
On Wednesday, 22 May 2013 at 17:31:17 UTC, Jonathan M Davis wrote:
On Tuesday, May 21, 2013 22:32:00 Brad Anderson wrote:
Would the public import people are suggesting not work for
maintaining backward compatibility?
Also, couldn't you just do import uni = std.unicode to save on
typing in modul
On Wednesday, May 22, 2013 22:07:24 Brad Anderson wrote:
> On Wednesday, 22 May 2013 at 17:31:17 UTC, Jonathan M Davis wrote:
> > Of course we can provide a migration path, but you're still
> > talking about
> > breaking code, and I don't think that std.uni is a bad enough
> > name to merit
> > tha
On Wednesday, 22 May 2013 at 17:31:17 UTC, Jonathan M Davis wrote:
Of course we can provide a migration path, but you're still
talking about
breaking code, and I don't think that std.uni is a bad enough
name to merit
that.
More specifically, what I'm wondering is whether or not it's
consider
On 2013-05-21, 22:12, Jonathan M Davis wrote:
given that std.uni is actually one of the modules that you're _likely_
to have
to give the full path to
Uhm, you *do* know D has renamed imports, right?
import uni = std.unicode; // Look ma, even shorter than std.uni!
--
Simen
On Tuesday, May 21, 2013 23:25:47 deadalnix wrote:
> It isn't really a rename as a new module is being integrated. We
> can keep what we have under std.uni for a while. If you want the
> new hotness, go for std.unicode .
Except that std.uni already exists. It's just that we're adding a bunch more
On Tuesday, May 21, 2013 23:25:47 deadalnix wrote:
> It isn't really a rename as a new module is being integrated. We
> can keep what we have under std.uni for a while. If you want the
> new hotness, go for std.unicode .
Except that std.uni already exists. It's just that we're adding a bunch more
On Tuesday, May 21, 2013 22:32:00 Brad Anderson wrote:
> Would the public import people are suggesting not work for
> maintaining backward compatibility?
>
> Also, couldn't you just do import uni = std.unicode to save on
> typing in modules that make use of both std.ascii and std.unicode
> (that's
On 2013-05-21 19:53, Idan Arye wrote:
The problem is that people that need Unicode stuff see `std.utf` and
assume that all Unicode related stuff are there.
I never can remember if I should look in std.utf or std.uni. That
wouldn't change if it was renamed to std.unicode.
--
/Jacob Carlborg
On 05/21/2013 12:56 PM, Andrei Alexandrescu wrote:
> On 5/21/13 1:53 PM, Idan Arye wrote:
>> The problem is that people that need Unicode stuff see `std.utf` and
>> assume that all Unicode related stuff are there.
>
> I understand. Well, std.utf's documentation can always cross-reference
> into st
On Tue, 21 May 2013 16:51:01 +0400
Dmitry Olshansky wrote:
> The pitch by deadalnix:
>
> I strongly push into renaming it to std.unicode . As said in the
> other thread : uni can be unicode, but also unique, union, unit,
> uniform, unix, unijambist, whatever.
>
Or a British University. :)
FWI
21-May-2013 22:12, Brad Anderson пишет:
On Tuesday, 21 May 2013 at 17:53:02 UTC, Idan Arye wrote:
The problem is that people that need Unicode stuff see `std.utf` and
assume that all Unicode related stuff are there.
I see (and experience myself) a lot of confusion over this. Dealing with
stri
On Tue, 21 May 2013 19:23:36 +0100, Dmitry Olshansky
wrote:
21-May-2013 22:12, Brad Anderson пишет:
On Tuesday, 21 May 2013 at 17:53:02 UTC, Idan Arye wrote:
The problem is that people that need Unicode stuff see `std.utf` and
assume that all Unicode related stuff are there.
I see (and e
On 05/21/2013 12:56 PM, Andrei Alexandrescu wrote:
> On 5/21/13 1:53 PM, Idan Arye wrote:
>> The problem is that people that need Unicode stuff see `std.utf` and
>> assume that all Unicode related stuff are there.
>
> I understand. Well, std.utf's documentation can always cross-reference
> into st
On Tue, 21 May 2013 19:04:25 +0100, Simen Kjaeraas
wrote:
On 2013-05-21, 16:02, Regan Heath wrote:
On Tue, 21 May 2013 14:20:50 +0100, Dmitry Olshansky
wrote:
21-May-2013 17:03, Regan Heath пишет:
[snip]
[snip]
[snip]
Meaning if we can make an incremental change for the better
For b
On Tuesday, 21 May 2013 at 17:31:59 UTC, Andrei Alexandrescu
wrote:
On 5/21/13 1:27 PM, Steven Schveighoffer wrote:
Then we can correctly judge whether the name change is worth
doing. I
don't know that it is. std.uni is not immediately recognizable
as
something else, so it warrants a lookup in
On Tuesday, 21 May 2013 at 20:12:37 UTC, Jonathan M Davis wrote:
I'm completely against renaming it. It will break code for
little benefit. And
given that std.uni is actually one of the modules that you're
_likely_ to have
to give the full path to (in particular because std.ascii has
many of t
On Tuesday, 21 May 2013 at 19:40:03 UTC, eles wrote:
On Tuesday, 21 May 2013 at 18:23:42 UTC, Dmitry Olshansky wrote:
21-May-2013 22:12, Brad Anderson пишет:
On Tuesday, 21 May 2013 at 17:53:02 UTC, Idan Arye wrote:
I see people have no idea what Unicode is about.
Unicode is not only the encod
On Tuesday, 21 May 2013 at 18:23:42 UTC, Dmitry Olshansky wrote:
I see people have no idea what Unicode is about.
Unicode is not only the encoding - it's a de facto standard of
internationalization and related algorithms. UTF is encoding.
Point taken. Nevertheless, it's all still all rather c
On Tuesday, May 21, 2013 16:51:01 Dmitry Olshansky wrote:
> The pitch by deadalnix:
>
> I strongly push into renaming it to std.unicode . As said in the other
> thread : uni can be unicode, but also unique, union, unit, uniform,
> unix, unijambist, whatever.
>
> When theses pile up in a large lib
On Tuesday, 21 May 2013 at 18:23:42 UTC, Dmitry Olshansky wrote:
21-May-2013 22:12, Brad Anderson пишет:
On Tuesday, 21 May 2013 at 17:53:02 UTC, Idan Arye wrote:
The problem is that people that need Unicode stuff see
`std.utf` and
assume that all Unicode related stuff are there.
I see (and
On Tuesday, 21 May 2013 at 18:23:42 UTC, Dmitry Olshansky wrote:
21-May-2013 22:12, Brad Anderson пишет:
On Tuesday, 21 May 2013 at 17:53:02 UTC, Idan Arye wrote:
I see people have no idea what Unicode is about.
Unicode is not only the encoding - it's a de facto standard of
internationalizatio
On Tue, 21 May 2013 14:54:42 -0400, Nick Sabalausky
wrote:
On Tue, 21 May 2013 14:33:48 -0400
"Steven Schveighoffer" wrote:
"All symbols from a publicly imported module are also aliased in the
importing module. This means that if module D imports module C, and
module C publicly imports mo
On Tue, 21 May 2013 14:33:48 -0400
"Steven Schveighoffer" wrote:
> On Tue, 21 May 2013 14:23:24 -0400, Nick Sabalausky
> wrote:
>
> > module std.uni;
> > public import std.unicode;
> > alias std.unicode.foo foo;
> > alias std.unicode.bar bar;
> > pragma(msg, "Please import std.unicode instead
std.algo
std.uni // Ok
or
std.algorithm
std.unicode // OK
or
std.algorithm
std.uni --> WTF?
- newbie
On Tue, 21 May 2013 14:23:24 -0400, Nick Sabalausky
wrote:
module std.uni;
public import std.unicode;
alias std.unicode.foo foo;
alias std.unicode.bar bar;
pragma(msg, "Please import std.unicode instead of std.uni")
EOF
from here: http://dlang.org/module.html#ImportDeclaration
"All symbols
On Tuesday, 21 May 2013 at 17:53:02 UTC, Idan Arye wrote:
The problem is that people that need Unicode stuff see
`std.utf` and assume that all Unicode related stuff are there.
I see (and experience myself) a lot of confusion over this.
Dealing with strings a person constantly has to guess wh
On 2013-05-21, 16:02, Regan Heath wrote:
On Tue, 21 May 2013 14:20:50 +0100, Dmitry Olshansky
wrote:
21-May-2013 17:03, Regan Heath пишет:
[snip]
[snip]
[snip]
Meaning if we can make an incremental change for the better
For better how? The endless churn in my opinion is not worth the
i
On 5/21/13 1:53 PM, Idan Arye wrote:
The problem is that people that need Unicode stuff see `std.utf` and
assume that all Unicode related stuff are there.
I understand. Well, std.utf's documentation can always cross-reference
into std.unicode etc. Basically what I'm saying is that nowadays
se
On Tuesday, 21 May 2013 at 17:31:59 UTC, Andrei Alexandrescu
wrote:
On 5/21/13 1:27 PM, Steven Schveighoffer wrote:
Then we can correctly judge whether the name change is worth
doing. I
don't know that it is. std.uni is not immediately recognizable
as
something else, so it warrants a lookup in
On Tuesday, 21 May 2013 at 17:12:14 UTC, Jacob Carlborg wrote:
On 2013-05-21 14:51, Dmitry Olshansky wrote:
The pitch by deadalnix:
I strongly push into renaming it to std.unicode . As said in
the other
thread : uni can be unicode, but also unique, union, unit,
uniform,
unix, unijambist, wha
On 5/21/13 1:27 PM, Steven Schveighoffer wrote:
Then we can correctly judge whether the name change is worth doing. I
don't know that it is. std.uni is not immediately recognizable as
something else, so it warrants a lookup in the docs. Yes, less obvious,
but not horrifically misnamed. I don't th
On Tue, 21 May 2013 13:21:36 -0400, Idan Arye wrote:
When `std.regexp` was deprecated, they used a pragma for the deprecation
message:
https://github.com/D-Programming-Language/phobos/blob/2.062/std/regexp.d#L127L128
The same thing could be done for `std.uni`.
These past events have alrea
On Tue, 21 May 2013 13:08:46 -0400, Regan Heath
wrote:
On Tue, 21 May 2013 17:52:10 +0100, Steven Schveighoffer
wrote:
On Tue, 21 May 2013 12:43:01 -0400, Regan Heath
wrote:
On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer
wrote:
It has nothing to do with the name. I th
On Tuesday, 21 May 2013 at 16:52:06 UTC, Steven Schveighoffer
wrote:
On Tue, 21 May 2013 12:43:01 -0400, Regan Heath
wrote:
On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer
wrote:
It has nothing to do with the name. I think unicode is
better. But (allegedly) we have existing pro
On Tue, 21 May 2013 13:01:57 -0400, nazriel wrote:
On Tuesday, 21 May 2013 at 16:52:06 UTC, Steven Schveighoffer wrote:
Deprecated functions don't compile. Any code that uses it would have
to be modified.
They do. Unless you add compiler switch they will compile and only spit
out an
On 2013-05-21 18:11, nazriel wrote:
Also we have std.algorithm, std.process etc and nobody complains that
its name is too long.
They had the correct name to begin with. Why std.algorithm or
std.process wasn't shortened but std.uni was I have no idea.
std.algorithm is a lot newer than the othe
On 2013-05-21 14:51, Dmitry Olshansky wrote:
The pitch by deadalnix:
I strongly push into renaming it to std.unicode . As said in the other
thread : uni can be unicode, but also unique, union, unit, uniform,
unix, unijambist, whatever.
How about std.encoding.unicode to get a proper hierarchy i
On 2013-05-21 18:25, Steven Schveighoffer wrote:
I don't disagree, but is it so bad that it's worth changing the name?
That's all I'm saying, the bar has to be very high in order to require a
name change.
In general, changing the name of something without any added benefit
(aside from the benef
On Tue, 21 May 2013 17:52:10 +0100, Steven Schveighoffer
wrote:
On Tue, 21 May 2013 12:43:01 -0400, Regan Heath
wrote:
On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer
wrote:
It has nothing to do with the name. I think unicode is better. But
(allegedly) we have existing p
On Tuesday, 21 May 2013 at 12:51:05 UTC, Dmitry Olshansky wrote:
The pitch by deadalnix:
I strongly push into renaming it to std.unicode . As said in
the other thread : uni can be unicode, but also unique, union,
unit, uniform, unix, unijambist, whatever.
When theses pile up in a large libra
On Tuesday, 21 May 2013 at 16:52:06 UTC, Steven Schveighoffer
wrote:
On Tue, 21 May 2013 12:43:01 -0400, Regan Heath
wrote:
On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer
wrote:
It has nothing to do with the name. I think unicode is
better. But (allegedly) we have existing pro
On Tue, 21 May 2013 12:43:01 -0400, Regan Heath
wrote:
On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer
wrote:
It has nothing to do with the name. I think unicode is better. But
(allegedly) we have existing projects that use std.uni, which would
break if we renamed.
Wouldn
On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer
wrote:
On Tue, 21 May 2013 12:05:37 -0400, eles wrote:
On Tuesday, 21 May 2013 at 15:02:25 UTC, Steven Schveighoffer wrote:
On Tue, 21 May 2013 08:51:01 -0400, Dmitry Olshansky If the existing
module is std.uni, then let's keep std
I would say that new module should be called std.unicode. It is way
more clear what it does without looking up in docs. For code
breakage, maybe public import in std.uni + pragma-msg about
deprecation could lower it a bit?
+1
On Tue, 21 May 2013 12:05:37 -0400, eles wrote:
On Tuesday, 21 May 2013 at 15:02:25 UTC, Steven Schveighoffer wrote:
On Tue, 21 May 2013 08:51:01 -0400, Dmitry Olshansky If the existing
module is std.uni, then let's keep std.uni.
std.unicode would be better. But the code breakage is not wo
Also we have std.algorithm, std.process etc and nobody complains
that its name is too long.
On Tuesday, 21 May 2013 at 12:51:05 UTC, Dmitry Olshansky wrote:
The pitch by deadalnix:
I strongly push into renaming it to std.unicode . As said in
the other thread : uni can be unicode, but also unique, union,
unit, uniform, unix, unijambist, whatever.
When theses pile up in a large libra
On Tuesday, 21 May 2013 at 15:02:25 UTC, Steven Schveighoffer
wrote:
On Tue, 21 May 2013 08:51:01 -0400, Dmitry Olshansky If the
existing module is std.uni, then let's keep std.uni.
std.unicode would be better. But the code breakage is not
worth the change.
As far as restructuring, I don't
On Tue, 21 May 2013 08:51:01 -0400, Dmitry Olshansky
wrote:
The pitch by deadalnix:
I strongly push into renaming it to std.unicode . As said in the other
thread : uni can be unicode, but also unique, union, unit, uniform,
unix, unijambist, whatever.
When theses pile up in a large libr
On Tuesday, 21 May 2013 at 14:32:46 UTC, Domain wrote:
I vote for std.unicode. Actually, I thought it was std.uri at
the first glance. And I never thought uni is short for unicode.
+1
I wondered what uni meant the first time I read it as well. I
didn't know until I looked at the docs. I've ne
On Tuesday, 21 May 2013 at 12:51:05 UTC, Dmitry Olshansky wrote:
The pitch by deadalnix:
I strongly push into renaming it to std.unicode . As said in
the other thread : uni can be unicode, but also unique, union,
unit, uniform, unix, unijambist, whatever.
When theses pile up in a large libra
On Tue, 21 May 2013 14:20:50 +0100, Dmitry Olshansky
wrote:
21-May-2013 17:03, Regan Heath пишет:
[snip]
[snip]
If we make it a part of restructuring std.* that is long overdue then
I'm fine as long as package structure is well thought out as a whole.
Good structure can come about from a co
21-May-2013 17:03, Regan Heath пишет:
[snip]
My reservations:
If the chief benefit of renaming is aesthetics then I'd rather pass.
It's not aesthetics. It's to make it clear what the module is/does. I
read std.uni again recently, after being "away" from D for a while and
briefly wondered wha
On Tue, 21 May 2013 13:51:01 +0100, Dmitry Olshansky
wrote:
The pitch by deadalnix:
I strongly push into renaming it to std.unicode . As said in the other
thread : uni can be unicode, but also unique, union, unit, uniform,
unix, unijambist, whatever.
When theses pile up in a large libr
On 2013-05-21 14:51, Dmitry Olshansky wrote:
The pitch by deadalnix:
I strongly push into renaming it to std.unicode . As said in the other
thread : uni can be unicode, but also unique, union, unit, uniform,
unix, unijambist, whatever.
When theses pile up in a large library, this is more and mo
The pitch by deadalnix:
I strongly push into renaming it to std.unicode . As said in the other
thread : uni can be unicode, but also unique, union, unit, uniform,
unix, unijambist, whatever.
When theses pile up in a large library, this is more and more difficult
to rely on intuition/autocomp
72 matches
Mail list logo
