Robert Fraser wrote:
> 
> I think the implementation is all right, I just think the syntax needs to be reconsidered. Personally, I think the whole const-final-invariant thing is quite a bit nicer than any other implementation I've seen: being able to mark an object as invariant makes writing threadsafe code a lot easier. If there was a way to mark a class/struct as "invariant after being constructed," then it'd be unbeatable.

Frankly, I expect to be casting stuff to invariant constantly, based on the current design.


Sean

> I think that invariant-as-storage-class vs. const-as-storage-class is a false dichotomy, and also that they are incorrectly associated with the completely different type-constructors, const() and invariant().

I totally agree. It took me a while to accept that

const int i = 1; const(int) j = 1;

mean something totally different. Especially since for function parameters

void foo(const int* p);
actually is the same as
void foo(const(int*) p);

I think it'd be easier to understand if compile time constants used a
different keyword altogether and 'const type' was always the same
as 'const(type)', not just in function parameter declarations.

Christian

Bill Baxter wrote:
> What does it mean for D?  Well maybe For D maybe this could mean a third
> flavor of aggregate --
> - struct: low-level value aggregate
> - class: static polymorphic aggregate
> - dclass: dynamic polymorphic aggregate (new!)
> 
> The difference would be that dclass would do everything dynamically ('d' for "dynamic").  All member lookups via strings.  All property accesses via special methods that can be overridden.  In that way you could start coding with dclass, and as bottlenecks appear, you just have to transition the performance critical things from 'dclass' to 'class'. Another alternative is to allow some syntax for dynamic members in a class.  But that seems messier to me somehow.  For instance, from my experience using Qt I was constantly asking myself "should this be a slot? should that be a QProperty?"  Why worry?  Just make 'em all slots/properties.  If you need some non-dynamic things in your dclass, make an inner class that's not dynamic.

Hmm.  It's rather a shame this didn't get any replies.  I like the idea.  I wonder if MiniD helps out at all...

BA

On Fri, 29 Jun 2007 19:26:41 +0300, Brad Anderson <brad@dsource.org> wrote:

> Bill Baxter wrote:
>> What does it mean for D?  Well maybe For D maybe this could mean a third
>> flavor of aggregate --
>> - struct: low-level value aggregate
>> - class: static polymorphic aggregate
>> - dclass: dynamic polymorphic aggregate (new!)
>>
>> The difference would be that dclass would do everything dynamically ('d'
>> for "dynamic").  All member lookups via strings.  All property accesses
>> via special methods that can be overridden.  In that way you could start
>> coding with dclass, and as bottlenecks appear, you just have to
>> transition the performance critical things from 'dclass' to 'class'.
>> Another alternative is to allow some syntax for dynamic members in a
>> class.  But that seems messier to me somehow.  For instance, from my
>> experience using Qt I was constantly asking myself "should this be a
>> slot? should that be a QProperty?"  Why worry?  Just make 'em all
>> slots/properties.  If you need some non-dynamic things in your dclass,
>> make an inner class that's not dynamic.
>
> Hmm.  It's rather a shame this didn't get any replies.  I like the idea.  I
> wonder if MiniD helps out at all...
>
> BA

Yep, it's a shame (that there were no replies)... but maybe all just silently agreed? ;)

Bill Baxter schrieb am 2007-06-27:

[...]

> Yes, but "dynamic everything" is a big part of what makes GUIs so easy to write in a language like Python.  At the end of the day D is still going to be a statically typed language, so I don't think it'll ever be able to compete with a scripting language when it comes to the malleability of the code.
>
> For example in the program I'm writing in Python now I realized that it would be convenient to get some notification any time any member of a particular class got modified.  In Python it's a snap.  Just make a 10-line subclass that overrides __setattribute__ and use that instead of the original class and you're done.  None of the rest of the code I had written had to change a whit.  With D, the conversion would not be so easy, and in the end I'd still have to change client code here and there because foo.x+=5 doesn't work with D properties.
>
> That said, it's already a lot less painful writing GUI code in D than it is in C++ (GC, delegates, 'auto', and 'with' come to mind).  I just don't think a statically typed, compiled language will ever really be able to compete with a scripting language on the GUI front.
>
> On the other hand, a dynamic scripting language will never be able to compete with D on the speed front.  So you need both.  The price I pay for the convenience of being able to override __setattribute__ occasionally is that *all* attribute accesses have to happen via string lookups *all the time*.
>
> I tried Pyrex for the first time last week because I was worried my core math routines would become a bottleneck.  It's pretty impressive.  I really didn't think it would be so easy to use.  I don't even know if I have a bottleneck in the math yet, but Pyrex turned out to be so easy to use it was like "heck! why not?".
>
> I think the take home message is that people are quite willing to write/re-write performance critical parts of their code in a slightly restricted dialect if they can have unbounded expressiveness in the rest of their code.
>
> What does it mean for D?  Well maybe For D maybe this could mean a third
> flavor of aggregate --
> - struct: low-level value aggregate
> - class: static polymorphic aggregate
> - dclass: dynamic polymorphic aggregate (new!)
>
> The difference would be that dclass would do everything dynamically ('d' for "dynamic").  All member lookups via strings.  All property accesses via special methods that can be overridden.  In that way you could start coding with dclass, and as bottlenecks appear, you just have to transition the performance critical things from 'dclass' to 'class'. Another alternative is to allow some syntax for dynamic members in a class.  But that seems messier to me somehow.  For instance, from my experience using Qt I was constantly asking myself "should this be a slot? should that be a QProperty?"  Why worry?  Just make 'em all slots/properties.  If you need some non-dynamic things in your dclass, make an inner class that's not dynamic.

'dynamic light' is currently implemented in Flectioned (http://flectioned.kuehne.cn) as a prove of concept code for DMD.

# import cn.kuehne.flectionedCall : call;
# import std.stdio : writefln;
#
# class Test{
#    void bar(){
#        writefln("Test.bar");
#    }
#    void bar(int a, char[] b){
#        writefln("Test.bar(%s, \"%s\")", a, b);
#    }
# }
#
# void main(){
#    auto t = new Test();
#
#    call(t, "bar");
#    call(t, "bar", 6, "Erwin");
# }

The main stumbling block is that DMD and GDC use different calling conventions. I could implement the 'dclass' concept but am unsure how usefull it is.


Thomas

What python GUI did you use ?

Charlie

Daniel Keep wrote:
> 
> Walter Bright wrote:
>> ... A lot of people use Python, and are forced
>> to mix in C++ to speed up the slow parts. It would be much simpler for
>> them if they could use the same language for both.
> 
> I'll have to disagree on this.  I used Python for my third year
> comp.sci. group project, and it made things a hell of a lot easier.
> Most of the code was dealing with the GUI, with only a few math-heavy
> parts written by myself.
> 
> Using Python for the mathy parts made them so much easier to debug it
> wasn't funny, and I've never seen anything that could touch Python for
> writing sane GUI code.
> 
> In the end, I had to convert some of the slower code from Python to C,
> but that was basically a trivial exercise.  Pyrex allows you to write
> "Python-like" code that compiles directly to C that makes writing the
> native module wrapping C code a non-issue.
> 
> If I'd used just C++, the GUI coding would have driven me completely
> insane.  If I'd been restricted to an interpreted language, our app
> would have been slow as molasses.  By using Python, we got the best of
> both worlds :)
> 
> In a wacky kind of way, one of the reasons I chose Python was *because*
> it could be easily optimised.  True, it had to be done in a different
> language, but there was almost no effort required to do so, so I never
> had to fear hitting a performance ceiling.
> 
> 	-- Daniel

Oskar Linde wrote:
> Walter Bright skrev:
>> Oskar Linde wrote:
>>> Walter Bright skrev:
>>>> OF wrote:
>>>>> Walter Bright Wrote:
>>>>>
>>>>>> BLS wrote:
>>>>>>> I am afraid you will not like this idea, but not afraid enough. <g>
>>>>>>>
>>>>>>> Why not using a single keyword "const_" adding a number 1, 2, 3 to represent :
>>>>>>> invariant, final, readonlyview.
>>>>>>> the higher the number the higher (the stronger) the const.
>>>>>>> means : const_3 == invariant;
>>>>>>> At least a mental help, IMO; somehow borrowed from Modula 2 processes.
>>>>>> You're right, I don't like the idea <g>.
>>>>>
>>>>> I'm curious. Was 'readonly'
>>>>
>>>> readonly is a synonym for const, so no improvement there.
>>>
>>> Read-only isn't synonymous with constant.
>>
>> Consider ROM, i.e. "Read Only Memory".
> 
> Yes, there are cases where the meaning of read-only and constant overlap. You could even argue that the overlapping meanings are large enough to make the words synonymous, but that is irrelevant to the discussion.
> 
> What is relevant is which word does best describe the properties the D2.0 'const' has? IMHO, read-only wins by a large margin. Read-only describes everything 'const' is, while the generally accepted meaning of constant is a poor fit.
> 
> This has been irking me for quite some time, and I believe it is the reason the final-const-invariant thing feels so awkward (to me). The design has been carefully considered and is quite likely the best possible given the requirements. However, the use of "const" to mean read-only sticks out like a turd in a punch bowl (pardon the expression).
> 
> People argue that of the different meanings of "const" in C++ (that you like to point out), the non-constant meaning is the worst and most confusing. Still, the only meaning for "const" that D inherit from C++ is that one.
> 
> <parenthesis>
> I've never heard anyone complain about "const" as a "storage class", like in:
> 
> const double e = 2.7182818284590452354;
> const double pi = 3.14159265358979323846;
> <parenthesis>
> 
> I believe *many* people would be *much* less confused and have a *much* easier time acceping and grasping the D const behavior if better keywords were used. "What? Const means it can change???"
> 
> So I plead: Please reconsider the keywords. The implications of not doing that are severe. The publics acceptance of D is at stake.
> 
> What if you could say, "Look: We fixed C++'s const. Const now really means constant -- not could-actually-change and you will be damned if you assume anything else". This is a hypothetical scenario of changing final-const-invariant -> final-readonly-const. There could possibly be even better choices of keywords.
> 
> Apologies for being so harsh (and hyperbolic), but I feel this is (as strange as it may sound) a quite important issue.
> 
> /Oskar

I *highly* agree. As explained by Oskar, 'readonly' is a way better description for D2.0's const than 'const'. It is not just a "better" description, it is a more *accurate* and *correct* one. The only reason we have this concept named 'const' in D is pure C++ legacy mentality, as D's mutability system (final-const-invariant) was designed from C++ mutability system(just const). However, since D's mutability system is so different from C++'s, Walter, why would you want to maintain the 'const' keyword and not change it to something better?
Walter, please consider these arguments.

PS: If one wants a shorter alternative than 'readonly', I think the shorter 'rdonly' keyword would rapidly, and as easily, be assimilated by our programmer minds to represent the read-only concept.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D