This seems like a mistake.

It would require any new vendor(s) to contact all existing vendors to coordinate on a new number? What if the other vendors are out for the day/week/month, or are playing tricky practices?

Better not to rely on this, but rather have a number based on a UUID, or a domain name. (All vendors are going to have a domain name, aren't they?)

"Matthew" <matthew@stlsoft.org> wrote in message news:c40tfj$1ds2$1@digitaldaemon.com...
> This seems like a mistake.
>
> It would require any new vendor(s) to contact all existing vendors to coordinate on a new number? What if the other vendors are out for the day/week/month, or are playing tricky practices?

I recommend they use their trademarked name, which legitimate vendors try to make as unique and unconfusing as possible. There's nothing really stopping one vendor from masquerading as another, but they will probably earn the condemnation of the D user community for doing so.

> Better not to rely on this, but rather have a number based on a UUID, or a domain name. (All vendors are going to have a domain name, aren't they?)

UUID's are fine for computers, but are very unfriendly to type in. Domain names tend to be trademarked names.

"Walter" <walter@digitalmars.com> wrote in message news:c41p0k$2ps1$1@digitaldaemon.com...
>
> "Matthew" <matthew@stlsoft.org> wrote in message news:c40tfj$1ds2$1@digitaldaemon.com...
> > This seems like a mistake.
> >
> > It would require any new vendor(s) to contact all existing vendors to coordinate on a new number? What if the other vendors are out for the day/week/month, or are playing tricky practices?
>
> I recommend they use their trademarked name, which legitimate vendors try
to
> make as unique and unconfusing as possible. There's nothing really
stopping
> one vendor from masquerading as another, but they will probably earn the condemnation of the D user community for doing so.

How can anyone use a name in an enum?

> > Better not to rely on this, but rather have a number based on a UUID, or
a
> > domain name. (All vendors are going to have a domain name, aren't they?)
>
> UUID's are fine for computers, but are very unfriendly to type in. Domain names tend to be trademarked names.

"Matthew" <matthew@stlsoft.org> wrote in message news:c4236o$a3o$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:c41p0k$2ps1$1@digitaldaemon.com...
> >
> > "Matthew" <matthew@stlsoft.org> wrote in message news:c40tfj$1ds2$1@digitaldaemon.com...
> > > This seems like a mistake.
> > >
> > > It would require any new vendor(s) to contact all existing vendors to coordinate on a new number? What if the other vendors are out for the day/week/month, or are playing tricky practices?
> >
> > I recommend they use their trademarked name, which legitimate vendors
try
> to
> > make as unique and unconfusing as possible. There's nothing really
> stopping
> > one vendor from masquerading as another, but they will probably earn the condemnation of the D user community for doing so.
>
> How can anyone use a name in an enum?

I don't understand what you mean.

Walter wrote:
> "Matthew" <matthew@stlsoft.org> wrote in message
> news:c4236o$a3o$1@digitaldaemon.com...
> 
>>"Walter" <walter@digitalmars.com> wrote in message
>>news:c41p0k$2ps1$1@digitaldaemon.com...
>>
>>>"Matthew" <matthew@stlsoft.org> wrote in message
>>>news:c40tfj$1ds2$1@digitaldaemon.com...
>>>
>>>>This seems like a mistake.
>>>>
>>>>It would require any new vendor(s) to contact all existing vendors to
>>>>coordinate on a new number? What if the other vendors are out for the
>>>>day/week/month, or are playing tricky practices?
>>>
>>>I recommend they use their trademarked name, which legitimate vendors
> 
> try
> 
>>to
>>
>>>make as unique and unconfusing as possible. There's nothing really
>>
>>stopping
>>
>>>one vendor from masquerading as another, but they will probably earn the
>>>condemnation of the D user community for doing so.
>>
>>How can anyone use a name in an enum?
> 
> 
> I don't understand what you mean.
> 

I think he means this:

// Master list of D compiler vendors
enum Vendor
{
   DigitalMars = 1
}
// Which vendor we are
Vendor vendor = Vendor.DigitalMars;


Say I make a D compiler, I would have to tell all the other vendors to add me to the enum..


-- 
Christopher E. Miller

"Vathix" <vathix@dprogramming.com> wrote in message news:c42god$vp0$1@digitaldaemon.com...
> Walter wrote:
> > "Matthew" <matthew@stlsoft.org> wrote in message news:c4236o$a3o$1@digitaldaemon.com...
> >
> >>"Walter" <walter@digitalmars.com> wrote in message news:c41p0k$2ps1$1@digitaldaemon.com...
> >>
> >>>"Matthew" <matthew@stlsoft.org> wrote in message news:c40tfj$1ds2$1@digitaldaemon.com...
> >>>
> >>>>This seems like a mistake.
> >>>>
> >>>>It would require any new vendor(s) to contact all existing vendors to coordinate on a new number? What if the other vendors are out for the day/week/month, or are playing tricky practices?
> >>>
> >>>I recommend they use their trademarked name, which legitimate vendors
> >
> > try
> >
> >>to
> >>
> >>>make as unique and unconfusing as possible. There's nothing really
> >>
> >>stopping
> >>
> >>>one vendor from masquerading as another, but they will probably earn
the
> >>>condemnation of the D user community for doing so.
> >>
> >>How can anyone use a name in an enum?
> >
> >
> > I don't understand what you mean.
> >
>
> I think he means this:
>
> // Master list of D compiler vendors
> enum Vendor
> {
>     DigitalMars = 1
> }
> // Which vendor we are
> Vendor vendor = Vendor.DigitalMars;
>
>
> Say I make a D compiler, I would have to tell all the other vendors to add me to the enum..

Ah, I see now. I think the vendors would be willing to cooperate on this issue.

>> I think he means this:
>>
>> // Master list of D compiler vendors
>> enum Vendor
>> {
>>     DigitalMars = 1
>> }
>> // Which vendor we are
>> Vendor vendor = Vendor.DigitalMars;
>>
>>
>> Say I make a D compiler, I would have to tell all the other vendors to add me to the enum..
>
>Ah, I see now. I think the vendors would be willing to cooperate on this issue.

There should at least be an "unknown" vendor enum value so that a new
vendor can ship before the next revision of phobos comes out with
the "current vendor list".
If the string vendor name is in there they why even have the enum?
If the speed of doing a string compare is that important the user can
cache the vendor value somewhere:
int isDigitialMars = cmp(std.compiler.name,"Digital Mars D");

Let's say GDC comes out (not so hypothetical!). What does its compiler.d look like? If it has something like

    // Vendor specific string naming the compiler
    char[] name = "GNU D Compiler";

    // Master list of D compiler vendors
    enum Vendor
    {
        DigitalMars = 1
        GDC = 2;
    }

Then in order for user code that references Vendor.GDC to compile
you (meaning DMD) would need to make a release with that enum value.
So whenever a new compiler comes out every other compiler needs
to make a release with the new enum? hmmm.

Just use the strings as unique identifiers. The biggest pain
about using Java's System.getProperty("java.vendor") is that
the strings have to include the version information in the string
so it changes from release to release. Since std.compiler has
version numbers as ints the string can remain constant from release
to release.

-Ben

It's a really bad idea to expect any business to cooperate with competition :).

As was said, a string compare would work better because it doesn't rely on any cooperation.


Ben Hinkle wrote:
>>>I think he means this:
>>>
>>>// Master list of D compiler vendors
>>>enum Vendor
>>>{
>>>    DigitalMars = 1
>>>}
>>>// Which vendor we are
>>>Vendor vendor = Vendor.DigitalMars;
>>>
>>>
>>>Say I make a D compiler, I would have to tell all the other vendors to
>>>add me to the enum..
>>
>>Ah, I see now. I think the vendors would be willing to cooperate on this
>>issue.
> 
> 
> There should at least be an "unknown" vendor enum value so that a new
> vendor can ship before the next revision of phobos comes out with
> the "current vendor list".
> If the string vendor name is in there they why even have the enum?
> If the speed of doing a string compare is that important the user can
> cache the vendor value somewhere:
> int isDigitialMars = cmp(std.compiler.name,"Digital Mars D");
> 
> Let's say GDC comes out (not so hypothetical!). What does its
> compiler.d look like? If it has something like
> 
>     // Vendor specific string naming the compiler
>     char[] name = "GNU D Compiler";
> 
>     // Master list of D compiler vendors
>     enum Vendor
>     {
>         DigitalMars = 1
>         GDC = 2;	
>     }
> 
> Then in order for user code that references Vendor.GDC to compile
> you (meaning DMD) would need to make a release with that enum value.
> So whenever a new compiler comes out every other compiler needs
> to make a release with the new enum? hmmm. 
> 
> Just use the strings as unique identifiers. The biggest pain
> about using Java's System.getProperty("java.vendor") is that
> the strings have to include the version information in the string
> so it changes from release to release. Since std.compiler has
> version numbers as ints the string can remain constant from release
> to release.
> 
> -Ben

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:gtua60h5lcbj5lqtnb3as1rph0pfjgg642@4ax.com...
> There should at least be an "unknown" vendor enum value so that a new
> vendor can ship before the next revision of phobos comes out with
> the "current vendor list".
> If the string vendor name is in there they why even have the enum?
> If the speed of doing a string compare is that important the user can
> cache the vendor value somewhere:
> int isDigitialMars = cmp(std.compiler.name,"Digital Mars D");

That's a good idea, but I think having a two level set of names is a bit klunky.

> Let's say GDC comes out (not so hypothetical!). What does its compiler.d look like? If it has something like
>
>     // Vendor specific string naming the compiler
>     char[] name = "GNU D Compiler";
>
>     // Master list of D compiler vendors
>     enum Vendor
>     {
>         DigitalMars = 1
>         GDC = 2;
>     }
>
> Then in order for user code that references Vendor.GDC to compile
> you (meaning DMD) would need to make a release with that enum value.
> So whenever a new compiler comes out every other compiler needs
> to make a release with the new enum? hmmm.

Since it doesn't matter what the enum values are for various vendors, the customer can edit the compiler.d to put in any missing ones he needs.

> Just use the strings as unique identifiers. The biggest pain
> about using Java's System.getProperty("java.vendor") is that
> the strings have to include the version information in the string
> so it changes from release to release. Since std.compiler has
> version numbers as ints the string can remain constant from release
> to release.

Having the version number separate is a good idea <g>.

There seems to be some confusion here in some of the posts.  This is a library
module which can be overridden by your own as Walter suggests below.  There
never was any need for vendors to put out new versions of their compiler to keep
up.  If it's extended to include D software vendors in general, there are still
a lot of options open since any new vendor could put an overriding version in
their own release while they wait to be included in the standard module.
There isn't in nearly all cases even any need for a non-vendor user to compile a
modified version.  This could however, if strings are used for everything and
all software types vs each compiler are registered, become a rather huge module
quickly.  Enum of vendors and use of that for a support info matrix or for
(in)compatibility vectors would help a lot.

In article <c44knt$15kr$1@digitaldaemon.com>, Walter says...
>
>"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:gtua60h5lcbj5lqtnb3as1rph0pfjgg642@4ax.com...
>> There should at least be an "unknown" vendor enum value so that a new
>> vendor can ship before the next revision of phobos comes out with
>> the "current vendor list".
>> If the string vendor name is in there they why even have the enum?
>> If the speed of doing a string compare is that important the user can
>> cache the vendor value somewhere:
>> int isDigitialMars = cmp(std.compiler.name,"Digital Mars D");
>
>That's a good idea, but I think having a two level set of names is a bit klunky.
>
>> Let's say GDC comes out (not so hypothetical!). What does its compiler.d look like? If it has something like
>>
>>     // Vendor specific string naming the compiler
>>     char[] name = "GNU D Compiler";
>>
>>     // Master list of D compiler vendors
>>     enum Vendor
>>     {
>>         DigitalMars = 1
>>         GDC = 2;
>>     }
>>
>> Then in order for user code that references Vendor.GDC to compile
>> you (meaning DMD) would need to make a release with that enum value.
>> So whenever a new compiler comes out every other compiler needs
>> to make a release with the new enum? hmmm.
>
>Since it doesn't matter what the enum values are for various vendors, the customer can edit the compiler.d to put in any missing ones he needs.
>
>> Just use the strings as unique identifiers. The biggest pain
>> about using Java's System.getProperty("java.vendor") is that
>> the strings have to include the version information in the string
>> so it changes from release to release. Since std.compiler has
>> version numbers as ints the string can remain constant from release
>> to release.
>
>Having the version number separate is a good idea <g>.
>
>