Walter Bright wrote:
> Kirk McDonald wrote:
>>> alias super.foo foo;
>> That's not a workaround, nor is this considered a problem. This is the intended behavior.
> > Yes, and it took some extra effort to make sure it worked that way! In other words, it is not accidental or incidental behavior.
But perhaps alias isn't the right tool? Someone below suggested that this can cause problems when only one function out of several overloaded functions are desired. This can be coded around, but perhaps a more specific importation rule could be used. I can even see justification for co-opting import for this usage:
import package.function(arglist) as localName;
to be used within the class that is inheriting.
Actually, I'd prefer that this be the verb inherit rather than import, but that would probably mean adding a new reserved word.

Walter Bright wrote:
> Jeff Nowakowski wrote:
>> I think optimizing your language for vi and the printer is a dead-end. The vast majority of the time a developer is going to be working on his code on a computer using some tool. If a tool lets you make use of a big productivity feature, then it makes sense to use it and officially endorse it as a basic requirement of the language. Even vi users use tools like grep and ctags.
> > Everyone uses different tools, and particular tools may not be available
> on all platforms D is on.
> > FWIW, a lot of hard core programmers still use vi.
Cool; I'm hard core! Wait... does it still count if I'm using vim with a gui? :P
Incidentally, I tried switching to Code::Blocks so I would have a nice gui to use with ddbg, but in the end I went back to using ddbg on the command line; compared to vim, Code::Blocks' editor is crap :)
-- Daniel

BCS wrote:
> Reply to Chris Nicholson-Sauls,
> >> What we really need is a fix for the problem of casting to a Base
>> class "forgetting" overrides. Maybe a change to how vtbls work?
>> Okay, an example:
>>>> class Base {
>> int foo () { return 1; }
>> }
>> class Derived : Base {
>> override int foo () { return 2; }
>> }
>> What I'm thinking, is that Derived's copy of Base's vtbl should have
>> the pointer for .foo replaced with a pointer to its override. That
>> way, when cast to Base the entry still points to Derived's method.
>> Assuming the vtbl is prepared at compile-time, this shouldn't cause
>> any runtime issues... should it?
>>> > Unless I'm totally misreading you, that IS how it works.
> >
Hmm. I just re-tested this after your reply, and yes it does indeed work. I could swear that it didn't use to, or at least that there was some case that caused Base's implementation to be ran.
But since its apparently working right now... yay. :)
-- Chris Nicholson-Sauls

On Sun, 05 Aug 2007 11:06:10 -0700, Walter Bright wrote:
> FWIW, a lot of hard core programmers still use vi.
And I think that some are even still chipping away at granite blocks :)
--
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

On Sun, 05 Aug 2007 11:15:13 -0700, Walter Bright wrote:
> > Let me put it another way. How many people use a profiler?
BTW, I've tried to use the profiler a couple of times now, but the output is so obscure I can't work out what the hell it is trying to tell me.
--
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

Derek Parnell wrote:
> On Sun, 05 Aug 2007 11:15:13 -0700, Walter Bright wrote:
> >> Let me put it another way. How many people use a profiler?
> > BTW, I've tried to use the profiler a couple of times now, but the output
> is so obscure I can't work out what the hell it is trying to tell me.
I've used Quantify before and the UI it employs presents the information in an fairly clear manner. Not sure what there is on the non-commercial front though.
Sean

Derek Parnell wrote:
> BTW, I've tried to use the profiler a couple of times now, but the output
> is so obscure I can't work out what the hell it is trying to tell me.
Post a snippet of the output and point out what is unclear, and I'll try to help.

Derek Parnell wrote:
> On Sun, 05 Aug 2007 11:06:10 -0700, Walter Bright wrote:
>> FWIW, a lot of hard core programmers still use vi.
> > And I think that some are even still chipping away at granite blocks :)
I'm a command line interface curmudgeon. The reason is simple- it's more productive, since:
1) I can touch-type. There's no such thing as using a mouse without looking. Using a mouse is like being forced to type using only your left pinkie, and every program you use has a different keyboard layout.
2) I have muscle memory in my fingers, meaning a lot of complex commands can just spew out with no thought required.
3) Pipes are cool. Can't do the equivalent with a gui.
4) I routinely write simple batch files to automate whatever I'm doing at the moment. Can't do that with a gui.
5) Ever tried to do a series of repeated actions with a gui? Like, one by one, save all the emails in a folder to a text file? It's agonizing. With CLI, I'll just dude up a quick batch file using cut & paste, and it's done.
6) Most of the time I need a command, I've already done it, so I just type the first couple characters then F8, bam, I'm flying.
Guis have their uses - mainly for programs you aren't familiar with. But once you are familiar, CLI is faster.
P.S. I use microEmacs, not vi. Mainly because I have the source to it and just fix it to work like I want.

Derek Parnell wrote:
> On Sun, 05 Aug 2007 11:15:13 -0700, Walter Bright wrote:
> >> Let me put it another way. How many people use a profiler?
> > BTW, I've tried to use the profiler a couple of times now, but the output
> is so obscure I can't work out what the hell it is trying to tell me.
I smell a potential project here, a gui front-end for dmd profiler output, hmm... Sounds like something I'd like to try. I have been meaning to have a good look at the current GUI libraries for D.
Regan