On 09/07/2011 01:27 PM, Timon Gehr wrote:
> On 09/07/2011 09:30 AM, Jacob Carlborg wrote:
>> On 2011-09-06 19:39, Steven Schveighoffer wrote:
>>> I like enums in terms of writing code that processes them, but in terms
>>> of calling functions with them, I mean look at a sample fstream
>>> constructor in C++:
>>>
>>> fstream ifs("filename.txt", ios_base::in | ios_base::out);
>>>
>>> vs.
>>>
>>> File("filename.txt", "r+"); // or "rw"
>>>
>>> There's just no way you can think "rw" is less descriptive or
>>> understandable than ios_base::in | ios_base::out.
>>>
>>> -Steve
>>
>> BTW, I think that using:
>>
>> Mode.read | Mode.write
>>
>> Instead of "rw" is the same thing as one should name variables with a
>> proper descriptive names instead of just "a" or "b".
>>
>
> I disagree: "rw" is quite obvious because you have context. It is not
>
> Mode.read | Mode.write vs "rw"
>
> but
>
> File("filename.txt", Mode.read | Mode.write);
>
> vs
>
> File("filename.txt", "rw");
>
>
>

Oh, btw:

final switch(Mode.read|Mode.write){
    case Mode.read: writeln(1); break;
    case Mode.write: writeln(2); break;
}

=> 2

hm...

On Wednesday, September 07, 2011 13:32:46 Timon Gehr wrote:
> On 09/07/2011 01:27 PM, Timon Gehr wrote:
> > On 09/07/2011 09:30 AM, Jacob Carlborg wrote:
> >> On 2011-09-06 19:39, Steven Schveighoffer wrote:
> >>> I like enums in terms of writing code that processes them, but in
> >>> terms
> >>> of calling functions with them, I mean look at a sample fstream
> >>> constructor in C++:
> >>> 
> >>> fstream ifs("filename.txt", ios_base::in | ios_base::out);
> >>> 
> >>> vs.
> >>> 
> >>> File("filename.txt", "r+"); // or "rw"
> >>> 
> >>> There's just no way you can think "rw" is less descriptive or understandable than ios_base::in | ios_base::out.
> >>> 
> >>> -Steve
> >> 
> >> BTW, I think that using:
> >> 
> >> Mode.read | Mode.write
> >> 
> >> Instead of "rw" is the same thing as one should name variables with a proper descriptive names instead of just "a" or "b".
> > 
> > I disagree: "rw" is quite obvious because you have context. It is not
> > 
> > Mode.read | Mode.write vs "rw"
> > 
> > but
> > 
> > File("filename.txt", Mode.read | Mode.write);
> > 
> > vs
> > 
> > File("filename.txt", "rw");
> 
> Oh, btw:
> 
> final switch(Mode.read|Mode.write){
>      case Mode.read: writeln(1); break;
>      case Mode.write: writeln(2); break;
> }
> 
> => 2
> 
> hm...

Personally, I don't think that &ing or |ing enums should result in an enum, and this case illustrates one reason why. But ultimately, the main issue IMHO is that &ing or |ring enums doesn't generally result in a valid enum value, so it just doesn't make sense.

- Jonathan M Davis

On 2011-09-07 11:35, Walter Bright wrote:
> On 9/7/2011 12:35 AM, Jacob Carlborg wrote:
>> On 2011-09-06 20:00, Walter Bright wrote:
>>> On 9/6/2011 5:02 AM, Michel Fortin wrote:
>>>> What Apple does is meant to keep binary
>>>> compatibility.
>>>
>>> It doesn't work that well. dmd breaks with every new OS update.
>>>
>>> The winner with binary compatibility is, far and away, Microsoft.
>>
>> Maybe it would work better if you would use the proper API instead of
>> putting
>> __name_beg and __name_end around sections in the binary, i.e.
>> __minfo_beg and
>> __minfo_end.
>
> Actually, I did follow documented behavior of ld. Unfortunately, ld does
> not follow the documented behavior.

I don't know exactly what documentation you've read but this is what I've found:

http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html

http://developer.apple.com/library/mac/#documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html

The second link contains documentation for "getsectbyname" and similar functions for getting information and data from sections and segments. By using these functions __minfo_beg __minfo_end become unnecessary.

I have a fork of druntime that uses these functions. But at the same time I'm trying to make it work with dynamic libraries and I can't get TLS to work with dynamic libraries.

-- 
/Jacob Carlborg

On 09/07/2011 01:42 PM, Jonathan M Davis wrote:
> On 09/07/2011 01:27 PM, Timon Gehr wrote:
>>
>> Oh, btw:
>>
>> final switch(Mode.read|Mode.write){
>>       case Mode.read: writeln(1); break;
>>       case Mode.write: writeln(2); break;
>> }
>>
>> =>  2
>>
>> hm...

Actually, it will print nothing, not even an Assertion failure, my enum definition was wrong

>
> Personally, I don't think that&ing or |ing enums should result in an enum,
> and this case illustrates one reason why. But ultimately, the main issue IMHO
> is that&ing or |ring enums doesn't generally result in a valid enum value, so
> it just doesn't make sense.
>

Yes exactly. That is why I always use

alias int MODE;
enum:MODE{
    MODEread=1,
    MODEwrite=2,
}

On 2011-09-06 18:00:36 +0000, Walter Bright <newshound2@digitalmars.com> said:

> The winner with binary compatibility is, far and away, Microsoft.

Indeed, I think you're right that they are better than Apple. But you have to keep in mind that DMD doesn't depend on Microsoft's linker, and doesn't depend on Microsoft's C runtime. I bet you'd see more breakages otherwise.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2011-09-07 09:35:26 +0000, Walter Bright <newshound2@digitalmars.com> said:

> On 9/7/2011 12:35 AM, Jacob Carlborg wrote:
>> On 2011-09-06 20:00, Walter Bright wrote:
>>> On 9/6/2011 5:02 AM, Michel Fortin wrote:
>>>> What Apple does is meant to keep binary
>>>> compatibility.
>>> 
>>> It doesn't work that well. dmd breaks with every new OS update.
>>> 
>>> The winner with binary compatibility is, far and away, Microsoft.
>> 
>> Maybe it would work better if you would use the proper API instead of putting
>> __name_beg and __name_end around sections in the binary, i.e. __minfo_beg and
>> __minfo_end.
> 
> Actually, I did follow documented behavior of ld. Unfortunately, ld does not follow the documented behavior.

Indeed. Although nowhere in the documentation does it says what the linker does with empty sections, it is reasonable to assume they'd be treated like other sections (kept in the right order). But this has been proven unreliable and it turns out there are proper APIs to do what this hack was meant to do, so we should use them instead.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 9/7/11 12:09 AM, Jacob Carlborg wrote:
> Yeah, I hate that with Java interfaces, appending a number. Just because
> the good proper name is already taken and they can't break existing code.

I've been happy to see less of this recently.  Maybe it's just my imagination, but with build systems that have package management like Maven and Gradle becoming more widely adopted developers seem to be more content to let the package manager handle the versioning.  I hope this becomes the case with D too.

On 2011-09-07 14:23, Michel Fortin wrote:
> On 2011-09-07 09:35:26 +0000, Walter Bright <newshound2@digitalmars.com>
> said:
>
>> On 9/7/2011 12:35 AM, Jacob Carlborg wrote:
>>> On 2011-09-06 20:00, Walter Bright wrote:
>>>> On 9/6/2011 5:02 AM, Michel Fortin wrote:
>>>>> What Apple does is meant to keep binary
>>>>> compatibility.
>>>>
>>>> It doesn't work that well. dmd breaks with every new OS update.
>>>>
>>>> The winner with binary compatibility is, far and away, Microsoft.
>>>
>>> Maybe it would work better if you would use the proper API instead of
>>> putting
>>> __name_beg and __name_end around sections in the binary, i.e.
>>> __minfo_beg and
>>> __minfo_end.
>>
>> Actually, I did follow documented behavior of ld. Unfortunately, ld
>> does not follow the documented behavior.
>
> Indeed. Although nowhere in the documentation does it says what the
> linker does with empty sections, it is reasonable to assume they'd be
> treated like other sections (kept in the right order). But this has been
> proven unreliable and it turns out there are proper APIs to do what this
> hack was meant to do, so we should use them instead.
>

From the ld man page, section "Layout":

"All zero fill sections will appear after all non-zero fill sections in their segments."

-- 
/Jacob Carlborg

On 2011-09-07 16:33, David Gileadi wrote:
> On 9/7/11 12:09 AM, Jacob Carlborg wrote:
>> Yeah, I hate that with Java interfaces, appending a number. Just because
>> the good proper name is already taken and they can't break existing code.
>
> I've been happy to see less of this recently. Maybe it's just my
> imagination, but with build systems that have package management like
> Maven and Gradle becoming more widely adopted developers seem to be more
> content to let the package manager handle the versioning. I hope this
> becomes the case with D too.

Me too, that's why I'm working on a package manager.

-- 
/Jacob Carlborg

On Wednesday, September 07, 2011 14:16:55 Timon Gehr wrote:
> On 09/07/2011 01:42 PM, Jonathan M Davis wrote:
> > On 09/07/2011 01:27 PM, Timon Gehr wrote:
> >> Oh, btw:
> >> 
> >> final switch(Mode.read|Mode.write){
> >> 
> >>       case Mode.read: writeln(1); break;
> >>       case Mode.write: writeln(2); break;
> >> 
> >> }
> >> 
> >> =>  2
> >> 
> >> hm...
> 
> Actually, it will print nothing, not even an Assertion failure, my enum definition was wrong

Did you compile with -w? I don't remember if that affects final switch or not, but there's definitely a problem if you can get final switch to take a value that it doesn't handle without using a cast.

> > Personally, I don't think that&ing or |ing enums should result in an enum, and this case illustrates one reason why. But ultimately, the main issue IMHO is that&ing or |ring enums doesn't generally result in a valid enum value, so it just doesn't make sense.
> 
> Yes exactly. That is why I always use
> 
> alias int MODE;
> enum:MODE{
>      MODEread=1,
>      MODEwrite=2,
> }

And how is that any different from

alias int MODE;
enum MODEread = 1;
enum MODEwrite = 2;

They're manifest constants, not enum values. So, you're basically suggesting that flags be done with manifest constants as opposed to enums? That doesn't encapsulate as well IMHO, and I'd still object to a function having a MODE parameter, since that implies that a MODE is a single flag, whereas it's a group of flags - that and as far as Phobos goes, we don't generally use aliases like that (of course, we don't name types in all caps or start variable or enum value names with uppercase characaters either, so what Phobos does obviously isn't necssarily what you stick to).

- Jonathan M Davis