On 12/07/2012 18:09, Steven Schveighoffer wrote:
> 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

It depend what the function look like. if it is 60Mb + x where x is aproximatively proportional to the amount of code, it is fine.

On 12-07-2012 18:33, deadalnix wrote:
> On 12/07/2012 18:09, Steven Schveighoffer wrote:
>> 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
>
> It depend what the function look like. if it is 60Mb + x where x is
> aproximatively proportional to the amount of code, it is fine.

I don't think you're going to convince your average Android/iOS user to download 60+ MB for your app. :)

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Thu, 12 Jul 2012 12:46:29 -0400, Alex Rønne Petersen <alex@lycus.org> wrote:

> On 12-07-2012 18:33, deadalnix wrote:
>> On 12/07/2012 18:09, Steven Schveighoffer wrote:
>>> 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
>>
>> It depend what the function look like. if it is 60Mb + x where x is
>> aproximatively proportional to the amount of code, it is fine.
>
> I don't think you're going to convince your average Android/iOS user to download 60+ MB for your app. :)
>

Right.  For example, I had an app on my iPhone (that my wife downloaded) called "classic books", which I guess contained a few classic books.

It was 500MB.  I uninstalled it.  No self-respecting book reading application should be 500MB on iOS.  iBooks by apple is 52.5 MB with 200KB in data (i.e. books) from about 19 books.

That's under 60MB, and it does a hell of a lot more than print "Hello world".  Your app would get 1 star from me :)

Note that I went through this exercise recently because I ran out of space to take pictures.  The size *does* make a difference on a 16GB device that is used to store lots of media (pics and music).

You will have less opposition on a full platform with 500GB to 1TB of disk space, but notice how everyone complains that their computers run slower over time...  My answer is usually "install less shit".

-Steve

On Thursday, 12 July 2012 at 16:22:07 UTC, H. S. Teoh wrote:
> 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.

*cough* … DMD … *cough*.

On Thursday, 12 July 2012 at 16:22:07 UTC, H. S. Teoh wrote:
> I don't always have the time to work on it

... but when I do... :)

On 7/12/12 12:05 PM, Steven Schveighoffer wrote:
> 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.

I think we'll find ways to deprecate them later.

Andrei

On 12 July 2012 18:03, David Nadlinger <see@klickverbot.at> wrote:
> On Thursday, 12 July 2012 at 16:22:07 UTC, H. S. Teoh wrote:
>>
>> 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.
>
>
> *cough* … DMD … *cough*.

*cough* ... GDC ... *cough*

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

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.
>
> I think Christophe makes a great point. We've been all thinking inside the box but we should question the very existence of the box. Once the necessity of opCmp, opEquals, toHash, toString is being debated, we get to some interesting points:

Well, I'm not convinced it is a good idea to eliminate the stuff from Object, nor to remove const (I think RawObject as a base class of Object has merit, but to remove the Object functions for everyone? I'm very suspicious.)

Some problems I would point out with the idea of "eliminate the stuff from Object and use more templates instead":

1. Most importantly, the C++ template approach is a big pain for large-scale systems, because in such systems you want to create DLLs/SOs and C++ has neither a standard ABI nor a safe way to pass around template instantiations between DLLs (in the presence of changes to internal implementation details). Similar problems exist for D, yes? It's a lot easier to define a standard ABI for classes than to solve the cross-DLL template problem.

2. Although templates are used a lot in C++, in D programs they are used even more and this proposal would increase template usage, so I'd expect the bloat problem to increase. However, merging identical functions (identical machine code) might be a sufficient solution.

3. The need for more templates slows down compilation. We know this is a huge problem in C++.

4. Template bloat is no big deal on desktops but it becomes a bigger problem as the target system gets smaller. Maybe some compromise should be made to ensure D remains powerful and capable on small targets.

There were two proposals yesterday that I liked. Taken together, they address all the problems that were raised with const functions in Object:

1. Provide a 'safe workaround' for const, for caching and lazy evaluation (implement it carefully to avoid breaking the guarantees of immutable)
2. Provide a class modifier that makes immutable(_) illegal, so the class uses "logical const" instead of "physical const".

On 7/12/12 1:40 PM, David Piepgrass wrote:
> 1. Most importantly, the C++ template approach is a big pain for
> large-scale systems, because in such systems you want to create DLLs/SOs
> and C++ has neither a standard ABI nor a safe way to pass around
> template instantiations between DLLs (in the presence of changes to
> internal implementation details). Similar problems exist for D, yes?
> It's a lot easier to define a standard ABI for classes than to solve the
> cross-DLL template problem.

The thing is, that can be done in an opt-in manner. People who want methods in the root of the hierarchy can define a root that defines them. But there's no way to opt out of inheriting Object. Basically it's nice to not force people to buy into a constrained environment without necessity.

> 2. Although templates are used a lot in C++, in D programs they are used
> even more and this proposal would increase template usage, so I'd expect
> the bloat problem to increase. However, merging identical functions
> (identical machine code) might be a sufficient solution.

Yah, I think we have a pretty good attack at this problem.

> 3. The need for more templates slows down compilation. We know this is a
> huge problem in C++.

I, too, think this is a concern.

> 4. Template bloat is no big deal on desktops but it becomes a bigger
> problem as the target system gets smaller. Maybe some compromise should
> be made to ensure D remains powerful and capable on small targets.

I think virtuals are an equally, if not worse, problem in memory-constrained systems. The simple solution people choose for such - they use them judiciously. Here actually templates may be at an advantage because of their opt-in quality.

> There were two proposals yesterday that I liked. Taken together, they
> address all the problems that were raised with const functions in Object:
>
> 1. Provide a 'safe workaround' for const, for caching and lazy
> evaluation (implement it carefully to avoid breaking the guarantees of
> immutable)

We should explore this option in any case. At this point I'm starting to believe (a) we're doing the right thing by marginalizing the four methods aside from this issue, (b) caching is good for other things than this particular problem.

> 2. Provide a class modifier that makes immutable(_) illegal, so the
> class uses "logical const" instead of "physical const".

I think this would be considerably trickier.


Andrei

On 2012-07-12 15:48:13 +0000, "Steven Schveighoffer" <schveiguy@yahoo.com> said:

> 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?

Tail const is a orthogonal issue.

I just don't have time to work on this right now -- I'm too busy working on other thing -- even though I'd like very much to work on that.

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