On 12/12/2011 8:25 PM, Jonathan M Davis wrote:
> There have been a variety of suggestions on how to do it - including one
> similar to what you're suggesting with the this keyword. However, it still
> leaves the problem of disambiguation that I mentioned. What happens when
> there's a free function and a member function with the same name and same
> parameters? Which one gets called?
Member functions always take precedence in C#, and it works perfectly well. There's really no problem in practice.

On Monday, December 12, 2011 21:17:10 Mehrdad wrote:
> On 12/12/2011 8:25 PM, Jonathan M Davis wrote:
> > There have been a variety of suggestions on how to do it - including one similar to what you're suggesting with the this keyword. However, it still leaves the problem of disambiguation that I mentioned. What happens when there's a free function and a member function with the same name and same parameters? Which one gets called?
> 
> Member functions always take precedence in C#, and it works perfectly well. There's really no problem in practice.

I'm not saying that it can't be done. I'm just saying that all of the corner cases and the like have to be sorted out such that the feature is completely defined, and we don't have ambiguities that are going to cause problems. Things are complicated enough with alias this and opDispatch and the like. Adding yet another way to add functions to a type complicates things that much further. So, UFCS needs to be carefully designed, and that's more of an issue IMHO than the exact syntax used to determine if a function is supposed to work with UFCS.

- Jonathan M Davis

On 12/12/2011 3:31 AM, Manu wrote:
> I'd like to hear your comment on my last big email in this thread.

Eh, I need more help with which one you're talking about.

On 12/12/2011 9:28 PM, Jonathan M Davis wrote:
> On Monday, December 12, 2011 21:17:10 Mehrdad wrote:
>
>> Member functions always take precedence in C#, and it works perfectly
>> well. There's really no problem in practice.
> I'm not saying that it can't be done. I'm just saying that all of the corner
> cases and the like have to be sorted out such that the feature is completely
> defined, and we don't have ambiguities that are going to cause problems. Things
> are complicated enough with alias this and opDispatch and the like. Adding yet
> another way to add functions to a type complicates things that much further.
> So, UFCS needs to be carefully designed, and that's more of an issue IMHO than
> the exact syntax used to determine if a function is supposed to work with
> UFCS.
>
> - Jonathan M Davis
Just wondering, what _are_ the corner cases?

Whatever is already accessible through the object would automatically override -- whether it's alias this, opDispatch, or whatever. Only if everything fails, then would extension methods work.
Wouldn't that work?

On 2011-12-13 10:54, Mehrdad wrote:
> On 12/12/2011 9:28 PM, Jonathan M Davis wrote:
>> On Monday, December 12, 2011 21:17:10 Mehrdad wrote:
>>
>>> Member functions always take precedence in C#, and it works perfectly
>>> well. There's really no problem in practice.
>> I'm not saying that it can't be done. I'm just saying that all of the
>> corner
>> cases and the like have to be sorted out such that the feature is
>> completely
>> defined, and we don't have ambiguities that are going to cause
>> problems. Things
>> are complicated enough with alias this and opDispatch and the like.
>> Adding yet
>> another way to add functions to a type complicates things that much
>> further.
>> So, UFCS needs to be carefully designed, and that's more of an issue
>> IMHO than
>> the exact syntax used to determine if a function is supposed to work with
>> UFCS.
>>
>> - Jonathan M Davis
> Just wondering, what _are_ the corner cases?

The floating point syntax with an optional zero cause a conflict.

1. and .1


-- 
/Jacob Carlborg

On 2011-12-13 04:25:33 +0000, Jonathan M Davis <jmdavisProg@gmx.com> said:

> For arrays, all you need to do is have the first argument be an array, and that
> works great for arrays, but arrays don't have much in the way of functions
> built in, so there's no conflict.

Actually, there's still an open issue with array-member syntax and @property used together.


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

On Sat, 10 Dec 2011 22:32:17 +0100, Walter Bright <newshound2@digitalmars.com> wrote:

> On 12/10/2011 12:53 PM, maarten van damme wrote:
>> Could also someone shed some light on creating shared library's on linux? there
>> was some news about -fPIC beeing fixed but no real confirmation.
>
> Turns out there was a bug where EBX was not set correctly when calling a function that existed in a shared library. This bug was fixed. So we're ready to try again at creating a shared library with dmd.
>

On x86-64 the PIC code is working fine, but there were some relocation issues left.
https://github.com/dawgfoto/dmd/commits/SharedElf

I'm looking into wiring things up with the runtime,
but it requires quite some changes.

One thing I don't have a good answer too is how to handle registration
of a shared library loaded during runtime. Apparently we don't want
to synchronize all threads whenever a library gets loaded/unloaded.

martin

Le 12/12/2011 16:00, Timon Gehr a écrit :
> 
> I certainly don't confuse them (GC wouldn't be very interesting if the two were the same), and as I understand it there exist very few GC implementations that _guarantee_ responsiveness over a long time period. This effect gets a lot bigger as memory usage and reference mutation rate grow. It is very easy for a sufficiently big Java application, for instance, to get responsiveness problems.

Is the GC responsiveness increased when there are less objects to collect ? Wouldn't it be much increased if most small objects (strings, numbers, date/time objects that account) were managed by a ref counter and the other, user-defined objects left to the GC ?

On Mon, 12 Dec 2011 12:31:44 +0100, Jacob Carlborg <doob@me.com> wrote:

> On 2011-12-10 22:32, Walter Bright wrote:
>> On 12/10/2011 12:53 PM, maarten van damme wrote:
>>> Could also someone shed some light on creating shared library's on
>>> linux? there
>>> was some news about -fPIC beeing fixed but no real confirmation.
>>
>> Turns out there was a bug where EBX was not set correctly when calling a
>> function that existed in a shared library. This bug was fixed. So we're
>> ready to try again at creating a shared library with dmd.
>
> That's great to hear. We'll see how far we get this time.
>

What's the state of the OSX dylib code in dmd and druntime?

On 2011-12-13 13:12, Martin Nowak wrote:
> On Sat, 10 Dec 2011 22:32:17 +0100, Walter Bright
> <newshound2@digitalmars.com> wrote:
>
>> On 12/10/2011 12:53 PM, maarten van damme wrote:
>>> Could also someone shed some light on creating shared library's on
>>> linux? there
>>> was some news about -fPIC beeing fixed but no real confirmation.
>>
>> Turns out there was a bug where EBX was not set correctly when calling
>> a function that existed in a shared library. This bug was fixed. So
>> we're ready to try again at creating a shared library with dmd.
>>
>
> On x86-64 the PIC code is working fine, but there were some relocation
> issues left.
> https://github.com/dawgfoto/dmd/commits/SharedElf
>
> I'm looking into wiring things up with the runtime,
> but it requires quite some changes.
>
> One thing I don't have a good answer too is how to handle registration
> of a shared library loaded during runtime. Apparently we don't want
> to synchronize all threads whenever a library gets loaded/unloaded.
>
> martin

On Mac OS X there's a function available for that, "_dyld_register_func_for_add_image". I don't know if there's something similar available on Linux and FreeBSD.

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

-- 
/Jacob Carlborg