Eldar Insafutdinov wrote:
> Andrei Alexandrescu Wrote:
> Thanks for cooperation. I don't want to sound like I've given the
> right to ask for features, because I am working on a particular D
> project. But at the same time, indeed, while working on this project
> I found many things that I would like to be improved.
[snip]

Unfortunately we can't fix all of that stuff mostly because we wouldn't know what path is best to take. But we can and should fix this:

> class Test { void foo(); void foo() {} }

and this:

> 6) Various, various compiler bugs. I'm not joking here, I hit dmd
> bugs every single day I work on qtd. It makes it very difficult to
> cut down to sensible testcases, because of the size of the library. I
> filed some bugs, I used all my votes in bugzilla, but neither of
> those got any update within last 2 months. That's a pity. I am sure
> many other people have similar experience.
> 
> The main one is probably forward references bug. That's why I have to
> use patched version of dmd (done not by me). Work on it is still in
> progress, and when the author of the patches finishes it and submits
> them to the bugzilla, we would need apply them somehow, as otherwise
> official dmd will not compile QtD.

Absolutely.

Thanks for letting us know of the challenges you're facing. I hope many of them would be the start of discussions on how to improve things in D3.


Andrei

Andrei Alexandrescu Wrote:

> Eldar Insafutdinov wrote:
> > Andrei Alexandrescu Wrote:
> > Thanks for cooperation. I don't want to sound like I've given the
> > right to ask for features, because I am working on a particular D
> > project. But at the same time, indeed, while working on this project
> > I found many things that I would like to be improved.
> [snip]
> 
> Unfortunately we can't fix all of that stuff mostly because we wouldn't know what path is best to take. But we can and should fix this:
> 
> > class Test { void foo(); void foo() {} }
> 
> and this:
> 
> > 6) Various, various compiler bugs. I'm not joking here, I hit dmd bugs every single day I work on qtd. It makes it very difficult to cut down to sensible testcases, because of the size of the library. I filed some bugs, I used all my votes in bugzilla, but neither of those got any update within last 2 months. That's a pity. I am sure many other people have similar experience.
> > 
> > The main one is probably forward references bug. That's why I have to use patched version of dmd (done not by me). Work on it is still in progress, and when the author of the patches finishes it and submits them to the bugzilla, we would need apply them somehow, as otherwise official dmd will not compile QtD.
> 
> Absolutely.
> 
> Thanks for letting us know of the challenges you're facing. I hope many of them would be the start of discussions on how to improve things in D3.
> 
> 
> Andrei

So that means that annotations are pended until D3? I thought the work on @property will end up with proper annotations. Is it the same for your proposal with mixin(Derived)?

dsimcha wrote:
> == Quote from retard (re@tard.com.invalid)'s article
>> Sat, 12 Dec 2009 05:10:24 +0000, dsimcha wrote:
>>> 2.  Native look and feel.  IMHO this is very overrated.  I've never
>>> found that a Java-ish or GTK-ish or whatever look and feel instead of a
>>> native Win32 look and feel got in the way of me using a program
>>> effectively.
>> The win32 look and feel doesn't look native on linux/mac/solaris.
> 
> Right, the implication here was that I mostly use Windows and I've never really
> cared if an application I use has a GTK-ish or Swing-ish or whatever look and
> feel, as long as the application is well-coded, responsive and does what I need.
> I'm speaking purely from personal opinion/experience here, but I don't understand
> why people care so much about platform-native look and feel as long as it works
> and is usable.

I think native look and feel is a lot more important in, say, a web browser or a word processor. I don't care so much about which GUI toolkits Gnuplot or Mathematica use...

-Lars

On Mon, Dec 14, 2009 at 2:24 AM, Lars T. Kyllingstad <public@kyllingen.nospamnet> wrote:
> dsimcha wrote:
>>
>> == Quote from retard (re@tard.com.invalid)'s article
>>>
>>> Sat, 12 Dec 2009 05:10:24 +0000, dsimcha wrote:
>>>>
>>>> 2.  Native look and feel.  IMHO this is very overrated.  I've never found that a Java-ish or GTK-ish or whatever look and feel instead of a native Win32 look and feel got in the way of me using a program effectively.
>>>
>>> The win32 look and feel doesn't look native on linux/mac/solaris.
>>
>> Right, the implication here was that I mostly use Windows and I've never
>> really
>> cared if an application I use has a GTK-ish or Swing-ish or whatever look
>> and
>> feel, as long as the application is well-coded, responsive and does what I
>> need.
>> I'm speaking purely from personal opinion/experience here, but I don't
>> understand
>> why people care so much about platform-native look and feel as long as it
>> works
>> and is usable.
>
> I think native look and feel is a lot more important in, say, a web browser or a word processor. I don't care so much about which GUI toolkits Gnuplot or Mathematica use...

Non-native file dialogs which are bizarro (like gtk) or underpowered (like some Java ones) are the main thing that drive me crazy.  There's a lot of nice stuff built into the native Windows file dialogs.  It's very annoying when some non-native app takes all that away.

Also there are standard key-bindings.  Though probably any non-native app could be made to follow the platform conventions, the chances that a non-native LAF app will fail here are generally greater.  On Windows these are things like Alt-F4 to close app.  Ctrl-F4 or Ctrl-W to close a sub-window or document.  Ctrl-Tab to navigate tabs of a notebook-like widget, etc.   Also the way Alt works on Windows for controlling menus is something I've seen non-native apps futzing.

So basically I don't care much about non-native *look*, it's the non-native *feel* I find annoying.

--bb

Nick Sabalausky Wrote:

>    - Many GTK apps use the absolute *worst* and most impractical file dialog
> boxes I've seen in over 15 years. This is never an issue with native apps.

I like how gimp dialog box provides mruds, which is not done by virtually any other windows application, this is extremely useful, which is a practical concern.

Eldar Insafutdinov wrote:
> Andrei Alexandrescu Wrote:
> 
>> Eldar Insafutdinov wrote:
>>> Andrei Alexandrescu Wrote:
>>> Thanks for cooperation. I don't want to sound like I've given the
>>> right to ask for features, because I am working on a particular D
>>> project. But at the same time, indeed, while working on this project
>>> I found many things that I would like to be improved.
>> [snip]
>>
>> Unfortunately we can't fix all of that stuff mostly because we wouldn't know what path is best to take. But we can and should fix this:
>>
>>> class Test { void foo(); void foo() {} }
>> and this:
>>
>>> 6) Various, various compiler bugs. I'm not joking here, I hit dmd
>>> bugs every single day I work on qtd. It makes it very difficult to
>>> cut down to sensible testcases, because of the size of the library. I
>>> filed some bugs, I used all my votes in bugzilla, but neither of
>>> those got any update within last 2 months. That's a pity. I am sure
>>> many other people have similar experience.
>>>
>>> The main one is probably forward references bug. That's why I have to
>>> use patched version of dmd (done not by me). Work on it is still in
>>> progress, and when the author of the patches finishes it and submits
>>> them to the bugzilla, we would need apply them somehow, as otherwise
>>> official dmd will not compile QtD.
>> Absolutely.
>>
>> Thanks for letting us know of the challenges you're facing. I hope many of them would be the start of discussions on how to improve things in D3.
>>
>>
>> Andrei
> 
> So that means that annotations are pended until D3? I thought the work on @property will end up with proper annotations. Is it the same for your proposal with mixin(Derived)?

D2 will include properties that are understood by the compiler. We currently don't have a design for user-defined properties.

Andrei

On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
> D2 will include properties that are understood by the compiler. We currently don't have a design for user-defined properties.

Can I suggest something very simple: make them accessible from __traits, and leave the rest to the library. Accept @anything_at_all.

@myprop int a;

assert(__traits(getAnnotations, a) == [ "myprop" ]);


That's all the compiler needs to do. Then, in the library, we combine it with some magic to do the actual work. Something like this:

=========

class A {
	mixin(SIGNALS_AND_SLOTS!(A));

	@slot void fun() { }
}

string SIGNALS_AND_SLOTS(T)() {
	string data;
	static foreach(member, __traits(getMembers, T)) {
		static if(inArray(__traits(getAnnotations, member), "slot")) {
			data ~= "whatever implementation";
		}
	}

	return data;
}

==========


It is a little clunky, but it at least makes it accessible to libraries, where they can figure out some way to work with it. It seems like it should be fairly simple in the compiler - it is just keeping a list of strings.

> 
> Andrei

-- 
Adam D. Ruppe
http://arsdnet.net

Adam D. Ruppe wrote:
> On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
>> D2 will include properties that are understood by the compiler. We currently don't have a design for user-defined properties.
> 
> Can I suggest something very simple: make them accessible from __traits,
> and leave the rest to the library. Accept @anything_at_all.
> 
> @myprop int a;
> 
> assert(__traits(getAnnotations, a) == [ "myprop" ]);

Probably it's easier to (also) offer is(a == @myprop).

But we couldn't make static foreach part of D2.

Andrei

On Mon, Dec 14, 2009 at 07:42:51AM -0800, Andrei Alexandrescu wrote:
> Probably it's easier to (also) offer is(a == @myprop).

Yeah, that works too. As long as we have some kind of building block.

> But we couldn't make static foreach part of D2.

Oh well, no big deal; we can make do without it.

-- 
Adam D. Ruppe
http://arsdnet.net

Adam D. Ruppe wrote:
> On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
>> D2 will include properties that are understood by the compiler. We currently don't have a design for user-defined properties.
> 
> Can I suggest something very simple: make them accessible from __traits,
> and leave the rest to the library. Accept @anything_at_all.
> 
> @myprop int a;
> 
> assert(__traits(getAnnotations, a) == [ "myprop" ]);

I just had a little related idea. If you (Eldar) put the property in the naming convention, then you may be able to simplify things by using __traits(allMembers, Type), which works now.

For example: all signals start with "signal_" and all slots start with "slot_".

Would that work?


Andrei