On Thursday, 12 July 2012 at 04:15:48 UTC, Andrei Alexandrescu wrote:
> Required reading prior to this: http://goo.gl/eXpuX
>
> You destroyed, we listened.
> [...]
>
> What say you?
>
> Andrei

I agree, they are not needed.

This situation is similar to C#, but there the problem doesn't seem to be so severe.

Jon Skeet wrote on this long ago:

http://msmvps.com/blogs/jon_skeet/archive/2008/12/05/redesigning-system-object-java-lang-object.aspx

http://stackoverflow.com/questions/3096028/why-gethashcode-is-in-object-class

Daniel Murphy:

> This should be in the linker, not the backend.

What's important is that all D compilers implement this optimization (or something better, if compatible, like merging pieces of partially equal functions).

Bye,
bearophile

On Thursday, 12 July 2012 at 12:06:49 UTC, Roman D. Boiko wrote:
> Jon Skeet wrote on this long ago:

http://msmvps.com/blogs/jon_skeet/archive/2008/12/05/redesigning-system-object-java-lang-object.aspx

>The fact that every object has a monitor associated with it was a
>mistake in Java, and was unfortunately copied in .NET. This promotes the bad practice of locking on "this" and on types - both of which are typically publicly accessible references. I believe that unless a reference is exposed explicitly for the purpose of locking (like ICollection.SyncRoot) then you should avoid locking on any reference which other code knows about.

This has been discussed multiple times on the D forum, I believe.

On 2012-07-12 09:59, Jonathan M Davis wrote:

> For the most part, I think that operating on Objects like that is horrible,
> and we certainly don't encourage it, but it's been possible for ages, so I'm
> willing to bet that there's plenty of code which does it. For instance, what's
> Tango do? As I understand it, they're fairly Java-esque in their general
> approach to things, so it wouldn't entirely surprise me if their containers
> held Object rather than being templated (though the need to hold primitive
> types may have made it so that they didn't go that route).

All containers in Tango are templated classes, interfaces or structs. Just because Tango have more of a class hierarchy and nested packages than Phobos doesn't mean it doesn't use templates.

> 2. Will this work with toString? How much stuff relies on being able to get a
> string from Object? We've been switching everything in Phobos over to use
> variadic templates, which should make it easy enough to get around that
> problem (presumably, classes are then in the same boat as structs which don't
> define toString), but we may have older functions which will run into problems
> with this, and some stuff in other libraries could be completely screwed by
> this. Again, what does Tango do? Does it use variadic templates for its print
> function, or does it use D style variadics? At first glance, it seems to me
> that getting rid of toString on Object would screw over its use with D style
> variadics. That may or not be true, but if it is, we're closing doors on stuff
> which currently works.

Tango uses D style variadics for printing.

-- 
/Jacob Carlborg

On Thursday, 12 July 2012 at 12:36:18 UTC, RivenTheMage wrote:
> On Thursday, 12 July 2012 at 12:06:49 UTC, Roman D. Boiko wrote:
>> Jon Skeet wrote on this long ago:
>
> http://msmvps.com/blogs/jon_skeet/archive/2008/12/05/redesigning-system-object-java-lang-object.aspx
>
>>The fact that every object has a monitor associated with it was a
>>mistake in Java, and was unfortunately copied in .NET. This promotes the bad practice of locking on "this" and on types - both of which are typically publicly accessible references. I believe that unless a reference is exposed explicitly for the purpose of locking (like ICollection.SyncRoot) then you should avoid locking on any reference which other code knows about.
>
> This has been discussed multiple times on the D forum, I believe.

Do you mean Monitor or all other issues from that post as well? Do you have any links? I would be interested to know conclusions.

On 2012-07-12 13:41, bearophile wrote:

> There is no proof that template bloat won't be a problem in D (I
> remember the first version of the D Objective-C bridge failing because
> of code bloat, the second version seems to require changes in the D
> language).

Yeah, that was insane. 60 MB for a hello world application is not pretty.

The second version is not a bridge, it changes the language to be ABI compatible with Objective-C.

Supports extern(Objective-C) just as extern(C).

-- 
/Jacob Carlborg

On 2012-07-12 13:57, bearophile wrote:

> It's a requirement that comes from C specs, and I don't know why C was
> designed that way, as usual I am not expert enough. I prefer to not
> change the semantics of D over C unless there is an important reason,
> especially when I don't know/understand the rationale of the original C
> design :-)

But C doesn't have templates, is there some other case where this happens as well?

-- 
/Jacob Carlborg

Jacob Carlborg:

> Yeah, that was insane. 60 MB for a hello world application is not pretty.

I'd like to know how much MB are saved using the @templated()
pervasively in that first implementation... :-)


> The second version is not a bridge, it changes the language to be ABI
> compatible with Objective-C.<

I vaguely remember a language that allows to specify a custom
calling convention from the language itself. I don't know if this
general feature is worth adding to D.

Bye,
bearophile

On 2012-07-12 11:41:46 +0000, "bearophile" <bearophileHUGS@lycos.com> said:

> Andrei Alexandrescu:
> 
>> The issue is template code bloat. My impression from being in touch with the C++ community for a long time is that virtually nobody even talks about code bloat anymore. For whatever combination of industry and market forces, it's just not an issue anymore.
> 
> There is no proof that template bloat won't be a problem in D (I remember the first version of the D Objective-C bridge failing because of code bloat, the second version seems to require changes in the D language).

I don't think templates were the culprit for the D/Objective-C bridge. Code bloat was, but that's something that was inherent to the design of the bridge. The bridge was using mixins extensively, and while I did everything I could to use regular non-mixin templates (because those can be reused when the template arguments are the same), it wasn't enough. In fact, given that all the wrapper functions written using mixins were virtual (so you could override them, which is quite a feature!) it meant they all needed to be instantiated even though they were not used anywhere.

There's actually no way I could have reduced code bloat significantly even by writing all the code by hand in the most optimized way. Not unless I abandoned the capability to override functions, but that'd make the bridge almost useless.

One thing that might have helped is if the linker could have striped all the classes that were not used in the final executable, something it couldn't do because all module info refers to them. But that wouldn't have helped with the compilation speed, which was becoming the second problem not far behind code bloat.


>  And it seems L1 code caches of CPUs aren't growing a lot (so I suggest to not ignore having lot of code to swap in and out of those 32 kbytes).
> 
> So maybe it will be useful to introduce in D some means to attack the code bloat problem from several sides at the same time.
> 
> Some time ago I have suggested one of such weapons, the @templated() that allows to select what parts of a struct/class are templated regarding to what template arguments (it's a refinement of an idea of Stroustrup).
> 
> Another weapon to attack the problem is introducing in the DMD back-end an optimization (already present in LLVM, but I think not used on default), merging of functions with the same body (leaving just a jump as the body of the removed function, to keep their function pointers distinct).

Both desirable things, but I don't think those would have much impact on the D/Objective-C bridge.


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

On 7/12/12 3:59 AM, Jonathan M Davis wrote:
> If you can figure out how to make this work, it's fine by me.
>
> However, I see two potential issuses which cause currently working idioms to
> no longer work:
>
> 1. Anything which wants to be able to operate on Objects generically (e.g.
> have a container full of Objects) is going to have problems, since comparison
> and hashing won't work anymore. For the standard stuff, at minimum, that will
> screw up being able to put Object in AAs and RedBlackTree. For 3rd party
> containers which decided to go the Java route of containing Objects, they risk
> being completely screwed.

I've been thinking more about this and it's possible to keep good backwards compatibility by "marginalizing" instead of eliminating the four culprits.

Consider:

class A { void fun() {} }
class B : A { void fun() {} }
class C : A {}
void main() {
    A objA = new A;
    A objB = new B;
    A objC = new C;
    assert((&objA.fun).funcptr != (&objB.fun).funcptr);
    assert((&objA.fun).funcptr == (&objC.fun).funcptr);
}

In brief there _is_ a way to check during runtime whether a class has overridden a method.

If we define alternative free generic functions in object.d for the four culprit methods (and have the compiler, druntime, and stdlib use them instead of the methods), those functions can check whether a given class object has overridden the old-style functions. In that case, that means we're dealing with legacy classes and proceed the old-style way. Otherwise, proceed the new way.


Andrei