The Joys Of Programming

Use git.

boogle wrote:

Use git.

Thirded.

I will use git. The main thrust is the tracking of activity, not necessarily source control and versioning and such. However, as we already have a GitLab setup I'll just use that.

muraii wrote:

I will use git. The main thrust is the tracking of activity, not necessarily source control and versioning and such. However, as we already have a GitLab setup I'll just use that.

You could probably set up some sort of commit hook to call your tracking system's API, if it has one, to update the activity.

So PragProg is having another sale, in case you're upset you missed the previous one.

Save 40% on ebooks (epub, mobi and PDF) at pragprog.com with code Valentine2014, now through Valentine's Day.

C# again
and why the hell do I have to declare implementations of interface methods as public, they can't be anything else!

structural equality in C# is the most god awful atrocious thing in computer science

edit: it's worse in C# because those bastards knew how terrible it was in Java when they designed it.

And in ASP.NET, why do I have declare ASP.NET controls as runat="server" when the app won't even compile if they're not?

RolandofGilead wrote:

C# again
and why the hell do I have to declare implementations of interface methods as public, they can't be anything else!

What?

You don't put an access modifier on an interface definition at all, it won't compile.

RolandofGilead wrote:

C# again
and why the hell do I have to declare implementations of interface methods as public, they can't be anything else!

1) Because the interface is checked for completeness after the declaration of the class.

2) Consistency. Someone casually reading your code isn't going to necessarily know whether or not a method satisfies an interface. If it's specified explicitly, then having the access modifier would be superfluous, but allowing it to be omitted would add cognitive load.

Ed Ropple wrote:
RolandofGilead wrote:

C# again
and why the hell do I have to declare implementations of interface methods as public, they can't be anything else!

1) Because the interface is checked for completeness after the declaration of the class.

2) Consistency. Someone casually reading your code isn't going to necessarily know whether or not a method satisfies an interface. If it's specified explicitly, then having the access modifier would be superfluous, but allowing it to be omitted would add cognitive load.

I am going to need diagrams and smaller words because that makes no sense whatsoever.

RolandofGilead wrote:
Ed Ropple wrote:
RolandofGilead wrote:

C# again
and why the hell do I have to declare implementations of interface methods as public, they can't be anything else!

1) Because the interface is checked for completeness after the declaration of the class.

2) Consistency. Someone casually reading your code isn't going to necessarily know whether or not a method satisfies an interface. If it's specified explicitly, then having the access modifier would be superfluous, but allowing it to be omitted would add cognitive load.

I am going to need diagrams and smaller words because that makes no sense whatsoever.

HA!

RolandofGilead wrote:

I am going to need diagrams and smaller words because that makes no sense whatsoever.

I didn't think it was that complex...

1) The compiler doesn't check to see if your class implements the interface it says it does until it finishes processing the class declaration (including all partial classes). It can't know it's public "because it's an interface method" without making the compiler more complex. Adding complexity to the compiler is defensible if the results are valuable, but the results aren't valuable because:

2) Somebody may not know that Process() satisfies IProcessable when reading your code. They do know it's a public method when you say it's public. Having some methods that lack a visibility specifier be private and others be public is going to confuse people unnecessarily.

Anders Hejlsberg, the lead architect for C#, knows what he's doing. There are not many places where C# does things unnecessarily (though a few of them are bad, especially around immutability and reseatable references).

Simple explanation that I hope is legal C#:

class Foo : Bar
{
void method1() { //something }
void method2() { //something }
}

What are the accessibility levels of method1 and method2 if you didn't have to specify public for interface methods?

SixteenBlue wrote:

Simple explanation that I hope is legal C#:

class Foo : Bar
{
void method1() { //something }
void method2() { //something }
}

What are the accessibility levels of method1 and method2 if you didn't have to specify public for interface methods?

In C# if you don't specify the default for a class is internal and members are private.

Internal just means "only visible to things in the same assembly".

The main reason why you have to put public on interface methods is because the lack of public means private to the compiler, and that's illegal.

That all being said, if you're using visual studio and hit ctrl-. when you declare the class with the interface and just say implement interface it will put public on there for you.

You missed my point. If you don't have to specify public on interface implementations then you can't look at my class and tell me which methods are public vs internal without also looking at my interface.

SixteenBlue wrote:

You missed my point. If you don't have to specify public on interface implementations then you can't look at my class and tell me which methods are public vs internal without also looking at my interface.

While that is true, and finally makes some sense, you also can't tell which methods are interface implementations because C# doesn't require 'override' like Java requires "@Override", which is worse than being required to include 'public'.

SixteenBlue wrote:

Simple explanation that I hope is legal C#:

class Foo : Bar
{
void method1() { //something }
void method2() { //something }
}

What are the accessibility levels of method1 and method2 if you didn't have to specify public for interface methods?

Public, again, because they failed to make you put in the more pertinent information in the declaration.

Ed Ropple wrote:

1) The compiler doesn't check to see if your class implements the interface it says it does until it finishes processing the class declaration (including all partial classes). It can't know it's public "because it's an interface method" without making the compiler more complex.

It has the same name, arguments and return type, what the **** else is it going to be?

2) Somebody may not know that Process() satisfies IProcessable when reading your code.

and that is not changed by the inclusion of 'public'

Conclusion, I should be irked by the lack of 'override' rather than the unnecessary inclusion of 'public'.

Java doesn't require override for interfaces. In fact it wasn't even an option until 6 I believe.

Which makes sense since you can't override an interface.

RolandofGilead wrote:
SixteenBlue wrote:

Simple explanation that I hope is legal C#:

class Foo : Bar
{
void method1() { //something }
void method2() { //something }
}

What are the accessibility levels of method1 and method2 if you didn't have to specify public for interface methods?

Public, again, because they failed to make you put in the more pertinent information in the declaration.

Wrong only method1 is public. Method2 is not part of the interface and is internal. See the problem now?

This is why I like to use #regions extensively. Whenever I implement an interface, I like to surround the methods with

#region InterfaceName Implementation
...
#endregion InterfaceName Implementation

Plus I always put public/private/etc in front of every method to avoid any question about the scope of said method.

SixteenBlue wrote:

Java doesn't require override for interfaces. In fact it wasn't even an option until 6 I believe.

Which makes sense since you can't override an interface.

@Override is a case where you try to make one thing mean two things. Originally in Java 5 it was meant to denote that you were overriding a base class implementation. Which makes sense, at least as far as the name is concerned. But people complained that you could not use it (the compiler would emit an error) if you were implementing an interface method. So they allowed that and @Override now means "overrides" as well as "implements". Of course it is not required so its utility is not as great as it could be. But it's Java.

IMAGE(http://3.bp.blogspot.com/_jWkmcNTRKFc/SwbEYnTQe8I/AAAAAAAAB8w/sR3UTUlAgfQ/s320/shrug.jpg)
What are ya gonna do?

The existence of compiler-meaningful annotations might be the biggest wart in Java. That or it's half-hearted implementation of autoboxing. Both are putrid.

I must have Eclipse configured to treat a missing @Override as an error then.

SixteenBlue wrote:
RolandofGilead wrote:
SixteenBlue wrote:

Simple explanation that I hope is legal C#:

class Foo : Bar
{
void method1() { //something }
void method2() { //something }
}

What are the accessibility levels of method1 and method2 if you didn't have to specify public for interface methods?

Public, again, because they failed to make you put in the more pertinent information in the declaration.

Wrong only method1 is public. Method2 is not part of the interface and is internal. See the problem now?

The problem is you're using the wrong definition of Bar, here's the definiton of Bar I was using:
interface Bar
{
void method1();
void method2();
}

It doesn't matter what the definition of Bar is, what matters is that your desired solution obfuscates the visibility levels of the methods being specified in Foo. Even if you have two methods in Bar, so what? You can't tell if the Foo.method3(), then, is internal or public without looking at the definition of Bar. The problem is not changed by you having two methods instead of one, it's endemic to what you propose.

And, while we're at it, I'd love for you to demonstrate a better general-purpose method of equality than structural equality, while bearing in mind that both Java and C# support referential equality just fine.

RolandofGilead wrote:

I must have Eclipse configured to treat a missing @Override as an error then.

SixteenBlue wrote:
RolandofGilead wrote:
SixteenBlue wrote:

Simple explanation that I hope is legal C#:

class Foo : Bar
{
void method1() { //something }
void method2() { //something }
}

What are the accessibility levels of method1 and method2 if you didn't have to specify public for interface methods?

Public, again, because they failed to make you put in the more pertinent information in the declaration.

Wrong only method1 is public. Method2 is not part of the interface and is internal. See the problem now?

The problem is you're using the wrong definition of Bar, here's the definiton of Bar I was using:
interface Bar
{
void method1();
void method2();
}

Exactly! It's ambiguous and that's bad.

WCF is this week's pain in my butt.
Well, WCF SOAP service and a monitoring app on our F5 load balancer.
But WCF is my whipping boy.

I'm not sure what's worse: that I've managed to tame Rhino for my game, or that I think it's easy to use now.

(Not Nashorn, because Rhino runs on iOS and Android.)

RolandofGilead wrote:

I am going to need diagrams and smaller words because that makes no sense whatsoever.

IMAGE(http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/200000/10000/0000/300/210313/210313.strip.sunday.gif)

Perforce being case sensitive folder / file names when Windows is not is a continual pain in my butt.

Garden Ninja wrote:

Perforce being case sensitive folder / file names when Windows is not is a continual pain in my butt.

I would've just said Perforce is a continual pain in my butt. There's a reason I keep my p4 workspace under a git repo.