On Thursday, 23 February 2012 at 22:01:43 UTC, F i L wrote:
> UTC, so wrote:
>> If you are not using an IDE or a mouse, this would be hell.
>
> lol wut? This isn't the 80's.
>
> In all seriousness, I think you're decoupling inherently ingrained pieces: the language and it's tools. The same way you *need* syntax highlighting to distinguish structure, you *should* have other productivity tools to help you analyze data-layout. It's not like these tools don't exist in abundance on every platform. And MS has pulled some really stupid shit in its day, but it's developer tools and support do not fall under that category.

No one said you shouldn't use IDE or any other tool, but i don't think it is healthy to design a language with such assumptions. Walter himself was against this and stated why he doesn't like Java way of doing things, one of the reason was the language was relying on IDEs.

I understand he is trying to fulfill a need that function qualifiers looks ugly yet i am not sure this is the answer.

On Thursday, 23 February 2012 at 17:10:58 UTC, Bruno Medeiros wrote:
> Sounds like a good idea.
> I would even add to this that it might be useful to have similar syntax that would allow to define an override method without having to specify the return type nor the parameters of the overridden method. Sometimes in class hierarchies there is a lot of redundancy when overriding methods and it could be a nice small feature to reduce that (especially for methods with lots of parameters).
>
> class Foo {
> 	int num;
> 	
> 	override opEquals {
> 		if(cast(Foo) o is null)
> 			return false;
> 		return this.num == (cast(Foo) o).num;
> 	}
> 	
> 	override toString {
> 		return to!(string)(num);
> 	}
> 	
> }

I don't like omitting argument names, but removing argument types seems nice.

On Fri, Feb 24, 2012 at 12:06:19AM +0100, Jason House wrote:
> On Thursday, 23 February 2012 at 17:10:58 UTC, Bruno Medeiros wrote:
> >I would even add to this that it might be useful to have similar syntax that would allow to define an override method without having to specify the return type nor the parameters of the overridden method. Sometimes in class hierarchies there is a lot of redundancy when overriding methods and it could be a nice small feature to reduce that (especially for methods with lots of parameters).
> >
> >class Foo {
> >	int num;
> >
> >	override opEquals {
> >		if(cast(Foo) o is null)
> >			return false;
> >		return this.num == (cast(Foo) o).num;
> >	}
> >
> >	override toString {
> >		return to!(string)(num);
> >	}
> >
> >}
> 
> I don't like omitting argument names, but removing argument types seems nice.

Omitting argument names/types is very evil. It opens up the possibility of changing the base class and introducing nasty subtle bugs in the derived class without any warning.  For example:

// Original code
	class Helper1 {
		void fun() { writeln("ABC"); }
	}
	class Helper2 {
		void fun() { writeln("DEF"); }
	}
	class Base {
		abstract void gun(Helper1 a, Helper2 b);
	}
	class Derived : Base {
		override void f( /* implicit arguments */) {
			a.fun();	// calls Helper1.fun
			b.fun();	// calls Helper2.fun
		}
	}

// New code
	class Helper {
		void fun() { writeln("ABC"); }
	}
	class Helper2 {
		void fun() { writeln("DEF"); }
	}
	class Base {
		// NB: argument names switched
		abstract void gun(Helper1 b, Helper2 a);
	}
	class Derived : Base {
		override void f( /* implicit arguments */) {
			// SEMANTICS CHANGED WITHOUT WARNING!
			a.fun();	// calls Helper2.fun
			b.fun();	// calls Helper1.fun
		}
	}

Similar problems occur if argument types are switched.


As for removing argument types, we could just use 'auto'. Perhaps the compiler can interpret 'override auto' to mean 'use base class's return type' instead of merely 'infer return type from function body'.


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."

On Thu, Feb 23, 2012 at 11:01:42PM +0100, F i L wrote:
> UTC, so wrote:
> >If you are not using an IDE or a mouse, this would be hell.
> 
> lol wut? This isn't the 80's.

I still don't use an IDE or a mouse when I code. And I don't plan to. (In fact, I rather plan the *opposite*.)


> In all seriousness, I think you're decoupling inherently ingrained pieces: the language and it's tools. The same way you *need* syntax highlighting to distinguish structure,

I don't.


> you *should* have other productivity tools to help you analyze data-layout. It's not like these tools don't exist in abundance on every platform.

I don't use them.


> And MS has pulled some really stupid shit in its day, but it's developer tools and support do not fall under that category.

True, they have their value. I don't argue with that.

But why should anyone be *forced* to use them? They're just tools. A language is a language (a set of syntax and grammar rules with the associated semantics). It's not inherently tied to any tools.


T

-- 
Microsoft is to operating systems & security ... what McDonalds is to gourmet cooking.

On Thursday, 23 February 2012 at 23:40:28 UTC, H. S. Teoh wrote:

> Omitting argument names/types is very evil. It opens up the possibility
> of changing the base class and introducing nasty subtle bugs in the
> derived class without any warning.  For example:

Good catch.

UTC, so wrote:
> No one said you shouldn't use IDE or any other tool, but i don't think it is healthy to design a language with such assumptions. Walter himself was against this and stated why he doesn't like Java way of doing things, one of the reason was the language was relying on IDEs.

Well then I disagree with Walter on this as well. What's wrong with having a "standard" toolset in the same way you have standard libraries? It's unrealistic to think people (at large) will be writing any sort of serious application outside of a modern IDE. I'm not saying it's Walters job to write IDE integration, only that the language design shouldn't cater to the smaller use-case scenario.

Cleaner code is easier to read and, within an IDE with tooltips, makes little difference when looking at the hierarchy. If you want to be hard-core about it, no one is stopping you from explicitly qualifying each definition.

H. S. Teoh wrote:
>> In all seriousness, I think you're decoupling inherently ingrained
>> pieces: the language and it's tools. The same way you *need* syntax
>> highlighting to distinguish structure,
>
> I don't.

wait... you don't even use Syntax Highlighting? Are you insane, you'll go blind!


>> And MS has pulled some really stupid shit in its day, but it's
>> developer tools and support do not fall under that category.
>
> True, they have their value. I don't argue with that.
>
> But why should anyone be *forced* to use them? They're just tools. A
> language is a language (a set of syntax and grammar rules with the
> associated semantics). It's not inherently tied to any tools.

The only reason Visual Studio being so closely tied to C#/VB/etc is a bad thing is because it's closed source and ultimately designed as [yet another] developer lock-in (just good business right?). Beyond that it's really silly not to use VS cause of all the productive features it provides. MonoDevelop is catching up, but still quite a ways behind in some areas. No one is stopping anyone from writing code in Notepad.. but then, no one is stopping 3D artists from manually editing .obj files in Notepad either.

On Friday, 24 February 2012 at 00:01:52 UTC, F i L wrote:

> It's unrealistic to think people (at large) will be writing any sort of serious application outside of a modern IDE.

You would be surprised or i should rather say shocked? :)
I used to be an IDE fanatic as well, then i took an arrow...

On 2/23/12 6:01 PM, F i L wrote:
> It's unrealistic to think people (at large) will be writing any sort of
> serious application outside of a modern IDE.

You'd hate working for Facebook :o).

Andrie

On 2/23/12 6:01 PM, F i L wrote:
> It's unrealistic to think people (at large) will be writing any sort of
> serious application outside of a modern IDE.

You'd hate working for Facebook :o).

Andrei