December 14, 2011
Michel Fortin wrote:
> Or should we invent a syntax such as array.(other.module.front)?

I think the syntax should be:
array.(~[{*&=>other.module.front}])();


no, in all honesty is there a reason the syntax you came up with wouldn't work?

   module foo;

   struct Foo {
       void bar() { ... }
   }

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   import foo;
   import a, b; // both define Foo.bar()

   void main() {
       auto foo = Foo();
       foo.bar();     // internal member
       foo.(a.foo)(); // module a
   }


December 14, 2011
On Tuesday, December 13, 2011 16:35:08 Michel Fortin wrote:
> Say you have a array-member property called "front" defined in std.range (not hard to imagine) and an identical property called "front" in another module and you import both modules: "array.front" becomes ambiguous. With the function call syntax you can write std.range.front(array) and other.module.front(array) as a substitute to the property syntax to disambiguate, but if the property syntax is enforced should calling the property as a function still be allowed for array-member functions? Or should we invent a syntax such as array.(other.module.front)?

Hmmm. Obviously, we either end up with a function that can't be called due to an ambiguity, or we need to find a way to resolve the ambiguity. And to resolve the ambiguity, we'd either have to allow for the property function to be called as a normal function or introduce a new syntax. Bleh.

The simplest solution would be to simply have the function callable as a non- property function when there's such an ambiguity, but that does go against the whole "require a property function to be used as a property" thing. Your suggested syntax is pretty good, but it's not exactly a desirable solution either. I don't know. Given the simplicity of it and the fact that there's no way that you're going to change the property function to a member variable (since it's not like you can add it to arrays), allowing for it to be called as normal function seems like the better solution, albeit not exactly ideal. Free functions definitely complicate the whole property thing.

- Jonathan M Davis
December 14, 2011
Jonathan M Davis wrote:
> The simplest solution would be to simply have the function callable as a non-
> property function when there's such an ambiguity, but that does go against the whole "require a property function to be used as a property" thing. Your suggested syntax is pretty good, but it's not exactly a desirable solution either. I don't know. Given the simplicity of it and the fact that there's no way that you're going to change the property function to a member variable (since it's not like you can add it to arrays), allowing for it to be called as normal function seems like the better solution, albeit not exactly ideal. Free functions definitely complicate the whole property thing.
>
> - Jonathan M Davis

Honestly I'm kind of a fan of having any method with zero or one parameters being usable as properties or methods at the programmer's discretion. Then conflicting pseudo methods could just be resolved through normal method semantics as you described. But I understand this is being removed so there must be a reason for it.

To bad the comma was used as new-line or we could remove the zero-or-one requirement all together and have Go-like return semantics:

   void foo(string a, int b, float c) { ... }

   float, float up() {
       return 0f, 1f;
   }

   void main() {
       foo = "bar", 1, 2.0f;
       float x, y = up;
   }

Of course, changing the language around like that is obviously not a realistic option. So this is just pointless speculation.
December 14, 2011
On 12/13/2011 4:12 AM, Martin Nowak wrote:
> On x86-64 the PIC code is working fine, but there were some relocation issues left.
> https://github.com/dawgfoto/dmd/commits/SharedElf

I see some good stuff there. When will you be ready for a pull request?
December 14, 2011
On Wednesday, December 14, 2011 03:45:35 F i L wrote:
> Jonathan M Davis wrote:
> > The simplest solution would be to simply have the function
> > callable as a non-
> > property function when there's such an ambiguity, but that does
> > go against the whole "require a property function to be used as
> > a property" thing. Your suggested syntax is pretty good, but
> > it's not exactly a desirable solution either. I don't know.
> > Given the simplicity of it and the fact that there's no way
> > that you're going to change the property function to a member
> > variable (since it's not like you can add it to arrays),
> > allowing for it to be called as normal function seems like the
> > better solution, albeit not exactly ideal. Free functions
> > definitely complicate the whole property thing.
> > 
> > - Jonathan M Davis
> 
> Honestly I'm kind of a fan of having any method with zero or one parameters being usable as properties or methods at the programmer's discretion. Then conflicting pseudo methods could just be resolved through normal method semantics as you described. But I understand this is being removed so there must be a reason for it.

It was in part due to ambiguity with regards to delegates. Also, a fairly typical argument for properties is the ability to swap public member variables and property functions. That's not possible if you can't classify a function such that it _must_ be called as a property.

- Jonathan M Davis
December 14, 2011
On 12/14/2011 06:25 AM, Jonathan M Davis wrote:
> On Wednesday, December 14, 2011 03:45:35 F i L wrote:
>> Jonathan M Davis wrote:
>>> The simplest solution would be to simply have the function
>>> callable as a non-
>>> property function when there's such an ambiguity, but that does
>>> go against the whole "require a property function to be used as
>>> a property" thing. Your suggested syntax is pretty good, but
>>> it's not exactly a desirable solution either. I don't know.
>>> Given the simplicity of it and the fact that there's no way
>>> that you're going to change the property function to a member
>>> variable (since it's not like you can add it to arrays),
>>> allowing for it to be called as normal function seems like the
>>> better solution, albeit not exactly ideal. Free functions
>>> definitely complicate the whole property thing.
>>>
>>> - Jonathan M Davis
>>
>> Honestly I'm kind of a fan of having any method with zero or one
>> parameters being usable as properties or methods at the
>> programmer's discretion. Then conflicting pseudo methods could
>> just be resolved through normal method semantics as you
>> described. But I understand this is being removed so there must
>> be a reason for it.
>
> It was in part due to ambiguity with regards to delegates. Also, a fairly
> typical argument for properties is the ability to swap public member variables
> and property functions. That's not possible if you can't classify a function
> such that it _must_ be called as a property.
>
> - Jonathan M Davis

The transition most of the time goes field -> property. Then it is not necessary at all. I think proper properties > implicit properties = no properties > implicit properties with enforcement.
December 14, 2011
On Tue, 13 Dec 2011 20:14:58 +0100, Walter Bright <newshound2@digitalmars.com> wrote:

> On 12/13/2011 6:15 AM, Martin Nowak wrote:
>> TLS is not too difficult. We can either use bracketed sections again or
>> let the compiler emit small thunks that fetch the complete TLS section for
>> a executable/DSO. The important point is that fetching the TLS addresses must
>> be done for each thread and from a local function within each DSO.
>> people.redhat.com/drepper/tls.pdf
>> My current approach is to register callbacks, and let the threads update
>> their ranges before GC.
>> Not sure, but it will probably causes eagerly allocation of the TLS blocks.
>>
>> Some similar issues happen with the other section brackets (.deh, .minfo).
>> We need local symbols as brackets not global ones as they would collide.
>>
>> I've tried several approaches.
>>
>> o Using a linker script with a recent binutils, add needed d sections
>> and use PROVIDE_HIDDEN to bracket them. Then it's only a matter
>> of adding constructor/destructor routines that register with druntime.
>>
>> It's not too feasible as newer binutils are default on linux only
>> and distributing linker scripts is not too nice either.
>>
>> o Create a C module similar to crt0.o that creates d sections and bracketing
>> symbols. Add constructor/destructor to register with druntime.
>>
>> The object file needs to be the first when linking, but the linker
>> can merge sections, thus there is only one registration per
>> executable/shared library.
>>
>> o Let the compiler generate a constructor/destructor for executables
>> and shared libraries. The object would also need to get linked first.
>>
>> This is less transparent than the 2nd option without much benefit.
>>
>> o Generate registration routines per object file. No bracketed sections.
>
> If the compiler generated static constructors and destructors ala C++ that would then be used to register the sections, that could hook into the existing C++ support code and not require special linker scripts and special object files.

I partly agree and will give that approach another try.
The huge drawback is that a shared library is self-contained w.r.t.
module construction, TLS and EH. When doing this on a per object base
the overhead increases with the number of linked objects and guaranteeing
ordered initialization becomes non-trivial.
December 14, 2011
On Wed, 14 Dec 2011 05:54:19 +0100, Walter Bright <newshound2@digitalmars.com> wrote:

> On 12/13/2011 4:12 AM, Martin Nowak wrote:
>> On x86-64 the PIC code is working fine, but there were some relocation issues left.
>> https://github.com/dawgfoto/dmd/commits/SharedElf
>
> I see some good stuff there. When will you be ready for a pull request?

I don't think that this belongs in the current release if that's what you meant.

So far I haven't found any regressions with these changes.
One part I'm not positive about is setting the size of public data symbols
to the DT size.
I also just found another issue with runtime relocations and EH so there will
be a little more in this direction but if you don't see any issues with the
data symbols we might as well merge it sooner than later.

martin
December 14, 2011
On 2011-12-14 11:17, Martin Nowak wrote:
> On Tue, 13 Dec 2011 20:14:58 +0100, Walter Bright
> <newshound2@digitalmars.com> wrote:
>
>> On 12/13/2011 6:15 AM, Martin Nowak wrote:
>>> TLS is not too difficult. We can either use bracketed sections again or
>>> let the compiler emit small thunks that fetch the complete TLS
>>> section for
>>> a executable/DSO. The important point is that fetching the TLS
>>> addresses must
>>> be done for each thread and from a local function within each DSO.
>>> people.redhat.com/drepper/tls.pdf
>>> My current approach is to register callbacks, and let the threads update
>>> their ranges before GC.
>>> Not sure, but it will probably causes eagerly allocation of the TLS
>>> blocks.
>>>
>>> Some similar issues happen with the other section brackets (.deh,
>>> .minfo).
>>> We need local symbols as brackets not global ones as they would collide.
>>>
>>> I've tried several approaches.
>>>
>>> o Using a linker script with a recent binutils, add needed d sections
>>> and use PROVIDE_HIDDEN to bracket them. Then it's only a matter
>>> of adding constructor/destructor routines that register with druntime.
>>>
>>> It's not too feasible as newer binutils are default on linux only
>>> and distributing linker scripts is not too nice either.
>>>
>>> o Create a C module similar to crt0.o that creates d sections and
>>> bracketing
>>> symbols. Add constructor/destructor to register with druntime.
>>>
>>> The object file needs to be the first when linking, but the linker
>>> can merge sections, thus there is only one registration per
>>> executable/shared library.
>>>
>>> o Let the compiler generate a constructor/destructor for executables
>>> and shared libraries. The object would also need to get linked first.
>>>
>>> This is less transparent than the 2nd option without much benefit.
>>>
>>> o Generate registration routines per object file. No bracketed sections.
>>
>> If the compiler generated static constructors and destructors ala C++
>> that would then be used to register the sections, that could hook into
>> the existing C++ support code and not require special linker scripts
>> and special object files.
>
> I partly agree and will give that approach another try.
> The huge drawback is that a shared library is self-contained w.r.t.
> module construction, TLS and EH. When doing this on a per object base
> the overhead increases with the number of linked objects and guaranteeing
> ordered initialization becomes non-trivial.

I don't think this is necessary to support dynamic libraries on Mac OS X. I think and hoping _dyld_register_func_for_add_image is sufficient.

-- 
/Jacob Carlborg
December 14, 2011
On 12/14/2011 2:17 AM, Martin Nowak wrote:
>> If the compiler generated static constructors and destructors ala C++ that
>> would then be used to register the sections, that could hook into the existing
>> C++ support code and not require special linker scripts and special object files.
>
> I partly agree and will give that approach another try.
> The huge drawback is that a shared library is self-contained w.r.t.
> module construction, TLS and EH. When doing this on a per object base
> the overhead increases with the number of linked objects and guaranteeing
> ordered initialization becomes non-trivial.

Yeah, I thought of that after I posted it.