July 12, 2012
On Thursday, 12 July 2012 at 09:32:00 UTC, Jonathan M Davis wrote:
> The issue that we're trying to solve here is making opEquals,opCmp, toHash, and toString work both for const and non-const objects. That's it. We're not talking about revamping const. It doesn't need it.

Depends on what you mean by 'need' I guess? You can either get rid of the cause or the effect, and either way that will get rid of the effect.


> this particular situation where OO and const collide needs a solution.
> ...
> That may mean that you can't use const in your code,

Right, I'm not. I'm not complaining about my code here.

My point is, there is _nothing_ about this problem that screams out "druntime" or "Phobos" to me.
It's a problem that can happen to _anyone_ using trying to use 'const' with base classes in OOP.

So if you're saying you can't use const with OOP, then I'm saying one of those needs to be fixed, and I was suggesting the former as a candidate.

But if you're saying this problem is somehow 'special' in some way, then would you please mention how?
July 12, 2012
On Thu, 12 Jul 2012 09:30:35 -0400, Michel Fortin <michel.fortin@michelf.com> wrote:

> D/Objective-C (the compiler addition) is much more than that. It's support and cohabitation of a second object ABI, it's support for Objective-C exceptions mixed with D exceptions, support for Objective-C string and selector literals, class objects and overridable class methods, overriding, contracts added to the Objective-C object model, Objective-C protocols (through interfaces), plus a few other things which haven't been implemented at this time.

Out of curiosity, do you see this becoming a possible improvement on D in the next year?

I have recently been doing iOS and Mac development with objective-c, and I am quite impressed with how well it works, and how easy it is to use, especially with xcode.

It would be nice to mix in a bit of D, using obj-c containers is a pain.

I remember the tail-const object reference was a blocker, no?  is there anything else?

-Steve
July 12, 2012
On Thursday, 12 July 2012 at 14:58:29 UTC, deadalnix wrote:
> I think this is not a problem as big as it is stated.
>
> Most of that code will be executed close to never, and 60Mb isn't a big deal for any modern computer, not even for most cell phones now.

L1 cache size is.
July 12, 2012
On Thu, 12 Jul 2012 10:56:13 -0400, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Thu, Jul 12, 2012 at 09:31:27AM -0400, Steven Schveighoffer wrote:
>> On Thu, 12 Jul 2012 00:15:48 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
> [...]
>> >3. opCmp, opEquals, and toHash are all needed primarily for one
>> >thing: built-in hashes. (There's also use of them in the moribund
>> >.sort method.) The thing is, the design of built-in hashes predates
>> >the existence of templates. There are reasons to move to
>> >generic-based hashes instead of today's runtime hashes (such as the
>> >phenomenal success of templated containers in C++), so it can be
>> >argued that opCmp, opEquals, and toHash exist for reasons that are
>> >going extinct.
>>
>> Yes.  Where's that new AA struct, Mr. Teoh? :)
> [...]
>
> The code is still here:
>
> 	https://github.com/quickfur/New-AA-implementation
>
> But I got roadblocked, partially because of constness issues
> (ironically, the problem was that toHash, toString, etc., weren't const,
> and now we're talking about supporting non-const versions of them), but
> more because of problems with IFTI. Or at least, that's where I left it
> about a month ago -- then I was away on vacation and haven't had the
> chance to go back to the code since. :(
>

Hm... chicken vs. egg again...

I think we need both the AA update and the removal of opX from object simultaneously.  Should we start a project branch for all the components?  (is that appropriate for git?)

-Steve
July 12, 2012
On 7/12/12 11:50 AM, Roman D. Boiko wrote:
> On Thursday, 12 July 2012 at 14:58:29 UTC, deadalnix wrote:
>> I think this is not a problem as big as it is stated.
>>
>> Most of that code will be executed close to never, and 60Mb isn't a
>> big deal for any modern computer, not even for most cell phones now.
>
> L1 cache size is.

That must be why he mentioned that most of that code won't be executed.

Andrei
July 12, 2012
On Thu, 12 Jul 2012 11:47:10 -0400, Mehrdad <wfunction@hotmail.com> wrote:

> But if you're saying this problem is somehow 'special' in some way, then would you please mention how?

Because you have no choice what your base class is -- Object.  And if Object uses const, so must you.

-Steve
July 12, 2012
On Thu, 12 Jul 2012 09:49:29 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 7/12/12 9:39 AM, Steven Schveighoffer wrote:
>> On Thu, 12 Jul 2012 09:20:47 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> 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.
>>
>> Hm... I don't like this, it slows down a very basic function.
>
> It's one comparison.
>
>> I think if we want a solution that allows old code to work, why not what
>> Timon suggested? Have a base class for Object (RawObject was suggested)
>> that does not implement the opFunctions. It would still break code, but
>> would be easy to fix (just specify your class derives from Object, not
>> RawObject).
>
> Too complicated. I think we can afford one comparison.

I don't know if it's one comparison, and really, we are doubling the vtable lookups.  I think the compiler should be able to optimize to one vtable lookup.

Aside from this, the baggage of four dead functions in every vtable is pretty hefty, is there a path to deprecation, or are the four horseman of the const apocalypse going to exist forever?  It would suck to have to deal with these issues forever.

-Steve
July 12, 2012
On Thu, 12 Jul 2012 10:58:28 -0400, deadalnix <deadalnix@gmail.com> wrote:


>>
>> Both desirable things, but I don't think those would have much impact on
>> the D/Objective-C bridge.
>>
>>
>
> I think this is not a problem as big as it is stated.
>
> Most of that code will be executed close to never, and 60Mb isn't a big deal for any modern computer, not even for most cell phones now.

You will never ever ever convince me that 60MB for a hello world program is "the norm", and should just be accepted on any platform.

-Steve
July 12, 2012
On Thu, Jul 12, 2012 at 11:51:15AM -0400, Steven Schveighoffer wrote:
> On Thu, 12 Jul 2012 10:56:13 -0400, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> 
> >On Thu, Jul 12, 2012 at 09:31:27AM -0400, Steven Schveighoffer wrote:
[...]
> >>Yes.  Where's that new AA struct, Mr. Teoh? :)
> >[...]
> >
> >The code is still here:
> >
> >	https://github.com/quickfur/New-AA-implementation
> >
> >But I got roadblocked, partially because of constness issues (ironically, the problem was that toHash, toString, etc., weren't const, and now we're talking about supporting non-const versions of them), but more because of problems with IFTI. Or at least, that's where I left it about a month ago -- then I was away on vacation and haven't had the chance to go back to the code since. :(
> >
> 
> Hm... chicken vs. egg again...
> 
> I think we need both the AA update and the removal of opX from object simultaneously.  Should we start a project branch for all the components?  (is that appropriate for git?)
[...]

Having more than just me working on the AA project would be a very good thing. I don't always have the time to work on it, and it's not fair to the community that the fate of such a vital component depends on the free time schedule of one person.


T

-- 
MS Windows: 64-bit overhaul of 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand 1-bit of competition.
July 12, 2012
On 12/07/2012 17:51, Andrei Alexandrescu wrote:
> On 7/12/12 11:50 AM, Roman D. Boiko wrote:
>> On Thursday, 12 July 2012 at 14:58:29 UTC, deadalnix wrote:
>>> I think this is not a problem as big as it is stated.
>>>
>>> Most of that code will be executed close to never, and 60Mb isn't a
>>> big deal for any modern computer, not even for most cell phones now.
>>
>> L1 cache size is.
>
> That must be why he mentioned that most of that code won't be executed.
>
> Andrei

Exactly.