On 23/12/2011 04:05, Jonathan M Davis wrote:
<snip>
> I mean that you have to be way more careful about how you name the flags. For
> instance, if you have
>
> MMM
>
> and
>
> Month
>
> you have issues with stuff like MMMonth.

To quote directly from the spec of my scheme:
"Each specifier is a letter, or two or more of the same letter consecutively (picked out by maximal munch before lookup in the following table)."
So this is a non-issue.

> It can definitely work, but the more
> flags that you have, the more problematic it becomes. It's also easier to
> separate out consecutive flags when reading them if you have %.

Here's the little bit of code in my library that finds the end of a flag:

    char letter = cast(char) std.ctype.tolower(*charPos);
    CPtr!(char) beginSpec = charPos;

    do {
        ++charPos;
    } while (std.ctype.tolower(*charPos) == letter);

Seems to me pretty straightforward.

>>> It's an interesting approach, but it isn't as
>>> flexible as it could be because of its use of maximul munch instead of %
>>> flags.
>> How do you mean?
>
> It's harder to have modifiers for flags without the %. For instance, what I'm
> doing with filler characters would be much more difficult with your scheme. With
> % delineating the flags, it becomes easier to handle that sort of thing.
<snip>

What are you doing with filler characters?  It appears to me, just allowing space or 0 as a filler character in some flags.  In my system, alignment fields provide a more powerful way of doing the same thing.

Stewart.

Le 22/12/2011 18:36, Andrei Alexandrescu a écrit :
> On 12/22/11 11:29 AM, Jacob Carlborg wrote:
>> On 2011-12-22 17:50, Andrei Alexandrescu wrote:
>>> On 12/22/11 4:40 AM, Jacob Carlborg wrote:
>>>> It would break code, but it's better to break it sooner than later. Seems more and more like D should support importing all modules in a package, that Java does:
>>>>
>>>> import foo.*;
>>>
>>> I think this style is currently discouraged in Java.
>>>
>>> Andrei
>>
>> Well, it seems like everyone wants it and there are several libraries that supports "import foo.all;" to include the whole "foo" package, including some of my own.
> 
> The authors of Java apparently thought the same. It is _experience_ with the actual feature that turned out to be bad. Last time I used Eclipse it underlined with red the lines with .*.
> 
> 
> Andrei

Yes, this style *is* discouraged in Java. In Python as well.

Modern IDE's like eclipse do all the tedious work automatically for you, so it's no longer a pain to have the full list of imports.

Le 22/12/2011 22:32, Jacob Carlborg a écrit :
>> The authors of Java apparently thought the same. It is _experience_ with the actual feature that turned out to be bad. Last time I used Eclipse it underlined with red the lines with .*.
>>
>>
>> Andrei
> 
> Really? I have not seen that. I have Eclipse 3.7.0 installed and it doesn't indicate and error with "import package.*;". Latest Eclipse is 3.7.1.
> 

It used to be warning, if I remember well.
In the current version of eclipse, all the * are automatically replaced
by the full names when saving. That's how it behaves here, at least.

And Andrei is correct about the fact that the star notation is considered sloppy, both in Java and in Python.

On Friday, December 23, 2011 10:17:00 Stewart Gordon wrote:
> On 23/12/2011 03:55, Jonathan M Davis wrote:
> <snip>
> 
> >> - If you're going to have the ISO week number in the system, it seems to me you should also have the week-numbering year.  (I've thought about possibly adding these to my scheme.)
> > 
> > %isoweek and %C2isoweek
> 
> What are you saying?  That the documentation is wrong, and %isoweek emits a year, not a week?

%isoweek emits a week. If it's not the week that you mean, then what are you talking about? I've obviously misunderstood.

> > Obviously, that needs to be clearer. The denominator is always a multiple of 10. It's what the mpeg-7 standard uses, which is why it's there.
> <snip>
> 
> What's that to do with it?  25000 _is_ a multiple of 10.  And 3/25000 contains 6 digits, compared to 12/100000's 8.  So the spec reads to the effect that %F should generate 3/25000 in that example.

Sorry. I meant power, not multiple. Wrong word. It's always a 1 followed by some number of 0s.

- Jonathan M Davis

On Fri, 23 Dec 2011 02:21:37 -0000, Walter Bright <newshound2@digitalmars.com> wrote:

> On 12/22/2011 11:25 AM, Piotr Szturmaj wrote:
>> I wish D could support partial modules - partial as analogy to C#'s partial
>> classes.
>>
>> module std.datetime-unit1;
>> import std.datetime-unit2;
>> // dash allowed only in submodules with the same module name
>> ...
>>
>> module std.datetime-unit2;
>> import std.datetime-unit1;
>> ...
>>
>> // then
>>
>> module whatever;
>> import std.datetime; // as usual
>
>
> I have no idea why anyone would want this. (Is it because the file is too big to fit on a floppy disk? <g>)

It's of most benefit (IMO) for the Visual Studio IDE/GUI designer code.  The automated code generation goes into one source file, in a partial class.  The user defined code into another source file/partial class.  It makes life easier for both the developer and the GUI designer code itself.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On 23/12/2011 11:04, Jonathan M Davis wrote:
> On Friday, December 23, 2011 10:17:00 Stewart Gordon wrote:
>> On 23/12/2011 03:55, Jonathan M Davis wrote:
>> <snip>
>>
>>>> - If you're going to have the ISO week number in the system, it seems
>>>> to me you should also have the week-numbering year.  (I've thought
>>>> about possibly adding these to my scheme.)
>>>
>>> %isoweek and %C2isoweek
>>
>> What are you saying?  That the documentation is wrong, and %isoweek emits a
>> year, not a week?
>
> %isoweek emits a week. If it's not the week that you mean, then what are you
> talking about? I've obviously misunderstood.

I said "week-numbering year".  How can that phrase mean a kind of week?

The week-numbering year is the year to which the ISO week belongs.  Most of the time this corresponds to the actual year, but around year boundaries it sometimes differs by 1.  For example, week 52 of 2011 goes from 2011-12-26 to 2012-01-01 inclusive.  The last of these dates isn't in the calendar year 2011, but it is still in the ISO week 2011-W52, so the week-numbering year is 2011.

Stewart.

On Friday, December 23, 2011 10:26:05 Stewart Gordon wrote:
> To quote directly from the spec of my scheme:
> "Each specifier is a letter, or two or more of the same letter consecutively
> (picked out by maximal munch before lookup in the following table)."
> So this is a non-issue.

So, your flags are even more restrictive than I understood them to be. You can't have multiple-character flags unless they're the same letter. I thought that you could. That _does_ avoid the problem that I was describing, but the result is too limiting IMHO. It certainly makes it hard to add flags for specific formats similar to %ctime or %mpeg7. It also means that you can't reuse letters.

> > It can definitely work, but the more
> > flags that you have, the more problematic it becomes. It's also easier
> > to
> > separate out consecutive flags when reading them if you have %.
> 
> Here's the little bit of code in my library that finds the end of a flag:
> 
>      char letter = cast(char) std.ctype.tolower(*charPos);
>      CPtr!(char) beginSpec = charPos;
> 
>      do {
>          ++charPos;
>      } while (std.ctype.tolower(*charPos) == letter);
> 
> Seems to me pretty straightforward.

The situation would be very different if you allowed multi-character flags of varying letters like I thought you did.

> >>> It's an interesting approach, but it isn't as
> >>> flexible as it could be because of its use of maximul munch instead
> >>> of % flags.
> >> 
> >> How do you mean?
> > 
> > It's harder to have modifiers for flags without the %. For instance, what I'm doing with filler characters would be much more difficult with your scheme. With % delineating the flags, it becomes easier to handle that sort of thing.
> <snip>
> 
> What are you doing with filler characters?  It appears to me, just allowing space or 0 as a filler character in some flags.  In my system, alignment fields provide a more powerful way of doing the same thing.

There's also the question of indicating the number of digits in the flag. In mine, it's quite easy to indicate either the exact number of digits that the result of the flag must be or to indicate that it must be _at least_ that many. And it's very consistent across flags. In yours, you have to do it with the casing of the letters, since the letters are all you have to work with. You have no modifiers. It may be that your alignment fields do a better job than the filler characters that I'm using, but I'd have to read over your spec again. I do remember thinking that the alignment fields didn't really add enough over using filler characters to be worth the extra complication.

It's possible that your scheme is somewhat easier to use for the most basic cases, but as soon as more specific and/or complicated schemes are needed (e.g. mpeg-7 or any of the ISO schemes), I don't think it works as well in general. I was trying to create a scheme that was flexible and powerful enough to do those more complicated schemes and yet still be easily usable for basic stuff. And I don't think that I'm all that far off from that, but it's quite possible that that extra power is making mine harder to use than yours for the most basic cases. I don't know.

- Jonathan M Davis

On Friday, December 23, 2011 11:21:48 Stewart Gordon wrote:
> I said "week-numbering year".  How can that phrase mean a kind of week?

Because I've never heard of it, and I misunderstood it.

> The week-numbering year is the year to which the ISO week belongs.  Most of the time this corresponds to the actual year, but around year boundaries it sometimes differs by 1.  For example, week 52 of 2011 goes from 2011-12-26 to 2012-01-01 inclusive.  The last of these dates isn't in the calendar year 2011, but it is still in the ISO week 2011-W52, so the week-numbering year is 2011.

A flag for that could be added easily enough.

- Jonathan M Davis

On 23/12/2011 11:23, Jonathan M Davis wrote:
<snip>
> So, your flags are even more restrictive than I understood them to be. You
> can't have multiple-character flags unless they're the same letter. I thought
> that you could. That _does_ avoid the problem that I was describing, but the
> result is too limiting IMHO. It certainly makes it hard to add flags for
> specific formats similar to %ctime or %mpeg7.

What is the use case for including a full date in some externally defined format within a longer formatted date string?  ISTM the way to do this is to define a function that just generates this format straight off.  In my library, toShortFormatString and toLongFormatString are already examples of this.

> It also means that you can't reuse letters.

At the moment only 12 letters are used.  I can't see the whole alphabet being used up any time in the foreseeable future.

<snip>
> It's possible that your scheme is somewhat easier to use for the most basic
> cases, but as soon as more specific and/or complicated schemes are needed (e.g.
> mpeg-7 or any of the ISO schemes), I don't think it works as well in general.
<snip>

I think I could expand my scheme to include ISO signed-year notation easily enough.  In the mpeg-7 standard, does the denominator of the fractional second have to be the smallest possible power of 10, or is F20/1000 or F0/1000 allowed just as well?

Stewart.

Andrei Alexandrescu wrote:
> On 12/22/11 1:25 PM, Piotr Szturmaj wrote:
>> I wish D could support partial modules - partial as analogy to C#'s
>> partial classes.
>>
>> module std.datetime-unit1;
>> import std.datetime-unit2;
>> // dash allowed only in submodules with the same module name
>> ....
>>
>> module std.datetime-unit2;
>> import std.datetime-unit1;
>> ....
>>
>> // then
>>
>> module whatever;
>> import std.datetime; // as usual
>
> I think there's a lot of mileage in the 1:1 correspondence between files
> and modules, and between directories and packages. We should keep it
> that way.

If you mean compatibility with build tools/compilers/parsers/IDEs/etc. then of course you are right. It's better to leave it as is.