On 11/10/2013 10:02 PM, Benjamin Thaut wrote:
> Am 11.11.2013 05:04, schrieb Walter Bright:
>>
>>
>> The trouble with dllexport and dllimport is the same module is both
>> depending on how it is used - I don't think that is very viable (C/C++
>> deal with this using macros). The idea is to use export for both, and
>> then use the context to figure out if it is dllimport or dllexport.
>>
>
> Still, how do you want to stop the compiler from referencing the module infos
> without knowing the module is part of a dll?

The compiler needs to know which modules are coming from a dll.

The only reference is in the import dependency list, which is used for static constructor calling. A dll's initialization should be self-contained and fully performed upon loading of the dll. The compiler should skip adding it to the import dependencies.

On 11/10/2013 10:19 PM, Benjamin Thaut wrote:
> Am 11.11.2013 05:17, schrieb Walter Bright:
>> On 11/10/2013 1:50 PM, Benjamin Thaut wrote:
>>
>> The compiler would benefit from knowing which modules are from a shared
>> library, and it needs to anyway in order to distinguish between
>> dllimport and dllexport.
>>
>
> Then you didn't understand the DIP correctly. One of the main points of this DIP
> is to provide a implementation of the export attribute that does _not_ require
> the compiler to know anything about, wether certain modules will end up in a DLL
> or not. With the proposed behaviour you could compile a module into an object
> file and then link it both into a DLL and static lirary. Both would just work.
> When using a library the compiler also doesn't have to know if the lirary is
> shared or static. Both will work and it will be decided at link time which path
> is coosen (static or shared). Generally this behaviour makes the export
> attribute easier to use and less error prone.

I do understand that. I just have strong doubts about whether that is the best approach or not.


> In an early version of this DIP did involve giving the compiler the information
> which modules end up in an shared library, but it was rejected in the
> discussion. A solution which does not require this information was preferred by
> almost all users taking part in the discussion.
>
>>
>> The trouble is, the proposed solution for exporting TLS variables is to
>> wrap the access in a function that is not inline-able anyway. For
>> performance oriented code, the user would be better off to write his own
>> wrapper, and then hoist the call out of the hot spot, and use a pointer
>> to the TLS variable in the hot spot.
>>
>> As a general rule, if code has a "hot spot" that crosses a DLL boundary,
>> there is going to be performance problems with it regardless. I don't
>> think this is a problem that the language can solve without some effort
>> from the user.
>
> Correct. But the compiler would still be able do other optimizations given the
> function is sligtly bigger then a simple getter.

That's possible, but I suspect much of the potential gains would be lost.

Am 11.11.2013 19:21, schrieb Walter Bright:
> On 11/10/2013 10:19 PM, Benjamin Thaut wrote:
>
> I do understand that. I just have strong doubts about whether that is
> the best approach or not.
>

So we throw 90% of the DIP away and you do a counter proposal?

On Sunday, 10 November 2013 at 12:39:35 UTC, Timon Gehr wrote:
> What about Object.factory?

I always though of it as a misfeature.

On 11/11/2013 11:02 PM, deadalnix wrote:
> On Sunday, 10 November 2013 at 12:39:35 UTC, Timon Gehr wrote:
>> What about Object.factory?
>
> I always though of it as a misfeature.

Me too.

On 11/11/13 2:36 PM, Timon Gehr wrote:
> On 11/11/2013 11:02 PM, deadalnix wrote:
>> On Sunday, 10 November 2013 at 12:39:35 UTC, Timon Gehr wrote:
>>> What about Object.factory?
>>
>> I always though of it as a misfeature.
>
> Me too.

... well time to substantiate.

Andrei

On Tuesday, 12 November 2013 at 05:46:19 UTC, Andrei Alexandrescu wrote:
> On 11/11/13 2:36 PM, Timon Gehr wrote:
>> On 11/11/2013 11:02 PM, deadalnix wrote:
>>> On Sunday, 10 November 2013 at 12:39:35 UTC, Timon Gehr wrote:
>>>> What about Object.factory?
>>>
>>> I always though of it as a misfeature.
>>
>> Me too.
>
> ... well time to substantiate.
>
> Andrei

OK, but first, it has to be noted that this is putting the burden of proof on the wrong side of the argument.

So I ran `grep -r * -e 'Object.factory'` on my d folder. I have various D project there. The only uses of Object.factory are the test suite of dmd, ldc and GDC.

I have bunch of D code in there, not simply mine. So first thing : it is unused.
Secondly, the only useful things you can do with that require to upcast (and break basic OOP principle, which is kind of ironic for a feature that produce objects). The design of the feature is unsound.

It is not that surprising as different possible uses case are better solved with compile time reflection and metaprograming.

Implementationwise, this feature require to pull into the application some unoptimizable bloat. It is also a tedious constraint for shared objects as we see in this thread.

On 11/11/13 10:59 PM, deadalnix wrote:
> On Tuesday, 12 November 2013 at 05:46:19 UTC, Andrei Alexandrescu wrote:
>> On 11/11/13 2:36 PM, Timon Gehr wrote:
>>> On 11/11/2013 11:02 PM, deadalnix wrote:
>>>> On Sunday, 10 November 2013 at 12:39:35 UTC, Timon Gehr wrote:
>>>>> What about Object.factory?
>>>>
>>>> I always though of it as a misfeature.
>>>
>>> Me too.
>>
>> ... well time to substantiate.
>>
>> Andrei
>
> OK, but first, it has to be noted that this is putting the burden of
> proof on the wrong side of the argument.

Well I'm not "burdening", just trying to figure how to do it better.

> So I ran `grep -r * -e 'Object.factory'` on my d folder. I have various
> D project there. The only uses of Object.factory are the test suite of
> dmd, ldc and GDC.

That really proves nothing.

> I have bunch of D code in there, not simply mine. So first thing : it is
> unused.
> Secondly, the only useful things you can do with that require to upcast
> (and break basic OOP principle, which is kind of ironic for a feature
> that produce objects). The design of the feature is unsound.

I think you're wrong here (even after one discounts for s/upcast/downcast/). There's no breakage of any basic OOP principle. There's no irony. Polymorphic creation aka the factory pattern is a classic in object-oriented design. You'd have a bad time arguing against it with anyone.

> It is not that surprising as different possible uses case are better
> solved with compile time reflection and metaprograming.

These don't take care of the dynamic case, which is sometimes needed (wherever factories are useful: serialization, scripting, ...).

> Implementationwise, this feature require to pull into the application
> some unoptimizable bloat.

This is a good point. But I presume the dedicated code is small in size.

> It is also a tedious constraint for shared objects as we see in this
> thread.

My reading of the thread is that there are concerns about DIP 45 beyond support of factories for shared objects.


Andrei

On 2013-11-12 07:59, deadalnix wrote:

> OK, but first, it has to be noted that this is putting the burden of
> proof on the wrong side of the argument.
>
> So I ran `grep -r * -e 'Object.factory'` on my d folder. I have various
> D project there. The only uses of Object.factory are the test suite of
> dmd, ldc and GDC.
>
> I have bunch of D code in there, not simply mine. So first thing : it is
> unused.

I used it in my serialization library, Orange, and it will be used in std.serialization when I finish that project.

-- 
/Jacob Carlborg

On Tuesday, 12 November 2013 at 07:16:03 UTC, Andrei Alexandrescu wrote:
> That really proves nothing.
>

That doesn't prove anything. But that doesn't smell good for the usefulness of the feature either.

>> I have bunch of D code in there, not simply mine. So first thing : it is
>> unused.
>> Secondly, the only useful things you can do with that require to upcast
>> (and break basic OOP principle, which is kind of ironic for a feature
>> that produce objects). The design of the feature is unsound.
>
> I think you're wrong here (even after one discounts for s/upcast/downcast/). There's no breakage of any basic OOP principle. There's no irony. Polymorphic creation aka the factory pattern is a classic in object-oriented design. You'd have a bad time arguing against it with anyone.
>

A Factory is always a factory of something. A factory fit nicely into the OOP paradigm as it allow the user of the object to not know what is the actual type of the object, but its interface.

A factory is also in charge of all the work necessary to put the object in a useful state. Object.factory do not allow any of this.

It doesn't make any sense to provide a factory of everything. The factory user will have to know what is built, at least partially to use it. This defeat the whole principle of a factory.

>> It is not that surprising as different possible uses case are better
>> solved with compile time reflection and metaprograming.
>
> These don't take care of the dynamic case, which is sometimes needed (wherever factories are useful: serialization, scripting, ...).
>

It is actually quite easy to create runtime capabilities from these basic blocs. CTFE allow to create AA, and at this point, the user can get whatever is desired at runtime.

This feature has more to do with runtime reflection than OOP.

>> Implementationwise, this feature require to pull into the application
>> some unoptimizable bloat.
>
> This is a good point. But I presume the dedicated code is small in size.
>

The code in itself isn't really the problem. The compiler have to emit a bunch of wiring to make it work. Wiring which is almost never used. Basically, the compiler have to emit runtime reflection informations, but just for classes.

This seems to be the wrong tradeoff : we get the constraint of runtime reflection in term of design, but with very limited benefices.

>> It is also a tedious constraint for shared objects as we see in this
>> thread.
>
> My reading of the thread is that there are concerns about DIP 45 beyond support of factories for shared objects.
>

This is A concern. Surely not the only one. That is why I didn't expanded myself on the subject in the first place. Simply that if we had to choose between this DIP and Object.factory, it is a braindead choice.