View mode: basic / threaded / horizontal-split · Log in · Help
July 12, 2012
Re: All right, all right! Interim decision regarding qualified Object methods
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
July 12, 2012
Re: All right, all right! Interim decision regarding qualified Object methods
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
July 12, 2012
Re: All right, all right! Interim decision regarding qualified Object methods
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.
July 12, 2012
Re: All right, all right! Interim decision regarding qualified Object methods
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
July 12, 2012
Re: All right, all right! Interim decision regarding qualified Object methods
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.
July 12, 2012
Re: All right, all right! Interim decision regarding qualified Object methods
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
July 12, 2012
Re: All right, all right! Interim decision regarding qualified Object methods
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
July 12, 2012
Re: All right, all right! Interim decision regarding qualified Object methods
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
July 12, 2012
Re: All right, all right! Interim decision regarding qualified Object methods
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/
July 12, 2012
Re: All right, all right! Interim decision regarding qualified Object methods
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
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home