The review process stalled long enough, let's kick start it with a small
yet a valuable module that was there for quite some time.
std.uuid by Johannes Pfau is a rehash of it's C++ twin from well known
Boost library.
The review cycle takes the usual 2 weeks starting today 9th June, ending
at
On 6/9/2012 10:30 AM, Dmitry Olshansky wrote:
The review process stalled long enough, let's kick start it with a small yet a
valuable module that was there for quite some time.
Great! My initial suggestion is that the parsing routines should accept input
ranges, rather just arrays.
On 09.06.2012 21:30, Dmitry Olshansky wrote:
The review process stalled long enough, let's kick start it with a small
yet a valuable module that was there for quite some time.
Ok, let's grill it a bit ;)
From browsing the docs alone:
ParserException - too general name likely to collide with
On Saturday, 9 June 2012 at 17:31:02 UTC, Dmitry Olshansky wrote:
The review process stalled long enough, let's kick start it
with a small yet a valuable module that was there for quite
some time.
When looking at the associated RFC I noticed that a UUID can
contain e.g. timestap, clock, node
Am Sun, 10 Jun 2012 12:03:15 +0200
schrieb "Jonas Drewsen" :
> When looking at the associated RFC I noticed that a UUID can
> contain e.g. timestap, clock, node fields. What about providing
> properties that could return these fields?
Why would you need those? A UUID only needs to be unique, wh
Am Sun, 10 Jun 2012 13:02:16 +0400
schrieb Dmitry Olshansky :
> On 09.06.2012 21:30, Dmitry Olshansky wrote:
> > The review process stalled long enough, let's kick start it with a
> > small yet a valuable module that was there for quite some time.
> >
>
> Ok, let's grill it a bit ;)
>
> From br
On 10.06.2012 15:22, Johannes Pfau wrote:
Am Sun, 10 Jun 2012 13:02:16 +0400
schrieb Dmitry Olshansky:
On 09.06.2012 21:30, Dmitry Olshansky wrote:
The review process stalled long enough, let's kick start it with a
small yet a valuable module that was there for quite some time.
Ok, let's gr
On Sunday, 10 June 2012 at 11:00:51 UTC, Johannes Pfau wrote:
Am Sun, 10 Jun 2012 12:03:15 +0200
schrieb "Jonas Drewsen" :
When looking at the associated RFC I noticed that a UUID can
contain e.g. timestap, clock, node fields. What about
providing properties that could return these fields?
W
If we use all caps for abbreviations then the names should be
SHA1UUID, MD5UUID and UUIDVersion?
On Jun 13, 2012 7:23 AM, "Kagamin" wrote:
>
> If we use all caps for abbreviations then the names should be SHA1UUID,
MD5UUID and UUIDVersion?
I believe tr naming scheme is acronyms have the same case. So if an
acronym is first it is all lowercase otherwise all uppercase.
On Saturday, June 09, 2012 21:30:57 Dmitry Olshansky wrote:
> Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
> API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
* I'm not terribly fond of having names like Variant and Version, but they
_are_ local to UUID, so I guess that
On 2012-06-14 03:57, Jonathan M Davis wrote:
On Saturday, June 09, 2012 21:30:57 Dmitry Olshansky wrote:
Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
* I'm not terribly fond of having names like Variant and Version, b
On 14.06.2012 10:35, Jacob Carlborg wrote:
On 2012-06-14 03:57, Jonathan M Davis wrote:
On Saturday, June 09, 2012 21:30:57 Dmitry Olshansky wrote:
Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
* I'm not terribly fond
On 09.06.2012 21:30, Dmitry Olshansky wrote:
The review process stalled long enough, let's kick start it with a small
yet a valuable module that was there for quite some time.
std.uuid by Johannes Pfau is a rehash of it's C++ twin from well known
Boost library.
The review cycle takes the usual
On 2012-06-14 08:57, Dmitry Olshansky wrote:
It feels this way because by default we import all symbols. The good
thing is that you don't care for conflicts as long as you don't touch
the conflicting name.
That's a good thing.
One day we'd just have to use static import more often.
Or alia
On Thursday, June 14, 2012 09:41:53 Jacob Carlborg wrote:
> On 2012-06-14 08:57, Dmitry Olshansky wrote:
> > It feels this way because by default we import all symbols. The good
> > thing is that you don't care for conflicts as long as you don't touch
> > the conflicting name.
>
> That's a good th
On 2012-06-14 09:49, Jonathan M Davis wrote:
It is and it isn't. It makes it much easier to end up with conflicts. It would
be less of a problem if not all symbols were imported by default. We _do_ have
some great tools for dealing with conflicts, but the fact that everything gets
imported by de
On Thursday, June 14, 2012 11:55:51 Jacob Carlborg wrote:
> > aliases are useless for dealing with conflicts as long as private aliases
> > aren't hidden. At present, I'd argue that private aliases are bad practice
> > unless you alias things to very esoteric names which aren't likely to
> > confli
On 2012-06-14 12:04, Jonathan M Davis wrote:
Actually, it's not. It's by design. private never hides _anything_ and is
always considered _after_ overload resolution. That's how it works in C++, and
that's how it works in D. If we want it to change, we need to convince Walter.
Personally, I think
Am Wed, 13 Jun 2012 18:57:51 -0700
schrieb Jonathan M Davis :
> * I'm not terribly fond of having names like Variant and Version, but
> they _are_ local to UUID, so I guess that they're clear enough. But
> the fact that you have to put a note about it _not_ being
> std.variant.Variant definitely i
On Saturday, June 16, 2012 13:27:54 Johannes Pfau wrote:
> Am Wed, 13 Jun 2012 18:57:51 -0700
> So I'd rather like to keep the name consistent with the RFC.
I understand. I don't think that there's a really a good solution. So, if you
think that keeping it as-is is best, then we can do that.
> _
Am Sat, 16 Jun 2012 16:57:25 -0700
schrieb Jonathan M Davis :
> Umm. My point was that as far as I can tell, what you're doing is
> _identical_ to what rndGen is doing.
>
Yes right now it's exactly the same. But there's no guarantee that the
'Random' alias (and therefore rndGen) will always use
On Sunday, June 17, 2012 09:42:40 Johannes Pfau wrote:
> Am Sat, 16 Jun 2012 16:57:25 -0700
>
> schrieb Jonathan M Davis :
> > Umm. My point was that as far as I can tell, what you're doing is
> > _identical_ to what rndGen is doing.
>
> Yes right now it's exactly the same. But there's no guarant
Am Sun, 17 Jun 2012 01:10:16 -0700
schrieb Jonathan M Davis :
> I seriously question that it will _ever_ be anything worse then
> Mt19997, but if you're that worried about it, maybe you should add a
> static assert that Random is Mt19997? If you want to leave it as-is,
> then you should probably a
24 matches
Mail list logo
