Musings

[andrewducker]

I've been coming to the conclusion that I don't like the way that methods return variables in C-like languages.  Having a single prioritised output parameter seems counterintuitive to me, and leads to two outcomes:
1) It's very easy to ignore/forget the return value.
2) If you have multiple return values then either one of them is the "proper" return value and the other one is passed back as a reference, or you pass back a tuple of some kind, or you have no return value and they both come back as references. 

It seems to me that it would be clearer and simpler if you always specified what parameters were in and out.

Rather than
string Reverse(string inputString)
you'd have
Reverse (string inputString, out string outputString)

This doesn't make a lot of difference when it comes to a simple method like that.  But if we take one with two outputs:

Do we use:
1) int GetMonthAndDay(DateTime inputDate, out int day)
2) MonthDayPair GetMonthAndDay(DateTime inputDate)
3) void GetMonthAndDay(DateTime inputDate, out int month, out int day)

The first one is clearly awful, the second one requires me to create an extra class, and the third one seems entirely clear.

Also, the use of different parameters means that you have smart method selection going on.
Convert(DateTime inputDate, out long seconds)
Convert(DateTime inputDate, out string nicelyFormatted)
makes it obvious from the parameters exactly what you're expecting to get back from it.

Of course, it does complicate very simple things:
DateTime tomorrow = today.AddDay();
would become
DateTime tomorrow;
today.AddDay(out tomorrow);

I suspect I'm just working on stuff where there are always multiple ins and outs, and also using generics and type inference, which doesn't work on return values, just parameters, and this is leading me to odd conclusions.

Comments

[davidcook.livejournal.com]

So you want to program in Ada, then ? A bold move :-)

procedure GetMonthAndDay(inputDate: in DateTime; month: out Integer; day: out Integer) is
begin
-- do stuff here
end GetMonthAndDay;

[andrewducker]

Doesn't surprise me that Ada works like that - they really valued clarity over everything else, didn't they?

[call-waiting.livejournal.com]

Ada does also have functions with return values, however, so it's just as easy to write the Horible Version in Ada as it is to write it in C#:

function getMonthAndDay(inputDate: in DateTime; day: out Integer) return Integer is
   ...

Just as with the C'ish languages, you need to have an enforced coding standard.

[figg.livejournal.com]

have fun with the following common operations:

f(g(x))

there is a reason we use that notaton as it's easy to combine functions.

p.s. in prolog does something very similar, and it's annoying as hell sometimes.

[andrewducker]

Oh, absolutely. It's not going to work for functional languages.

[figg.livejournal.com]

Um, no, It works quite well for prolog.

The problem is that function composition is a bitch
instead of doing


y = f(g(x)), you have to do f(x,x1), g(x1,y)

this gets very clumsy and annoying after a while.

Functions are useful for the common case of a single return, and in more mature languages you can return multiple values as pairs.

[andrewducker]

Aaah - I thought it would be even more ungainly than that. But then it's been a very long time since I played with Prolog.

Is there a nice way of returning pairs of values? Or do you just get back a class with two things in it, and have to hope that they're the right way round?

[figg.livejournal.com]

Prolog isn't object orientated, and abstract datastructures are a piece of piss.


To be frank, I haven't encounted such a problem with python, named parameters and easy tuples make this sort of problem a breeze.

Oh, and you're confusing strict and strong typing. Strict typing is type definition at compile time, and dynamic is at runtime.

Strong typing is the lack of implicit casts, and weak typing has implicit casting.


Oh, and saying 'hey intellisense makes this easy' is akin to 'hey this crutch makes it easy to walk with a broken leg'.

[andrewducker]

I didn't mean from Prolog. I meant from something that is object oriented. How does Python do it?

You're right about the casting - I meant static analysis, which is the "strict" side of things.

I don't understand your problem with intellisense. Care to elucidate?

[martling.livejournal.com]

Tuples are part of the core type system in Python. You don't have to declare a class to hold your tuple, you can just return "foo", 3. The same is true of most functional languages, e.g. (string, int) is a valid type in ML.

It's a shame this is missing from Java, it seems it was planned originally: http://gbracha.blogspot.com/2007/02/tuples.html

I gather that adding this to C# would be difficult now because essentially the CLR type system doesn't have the underlying support. F# has tuples in the language but the underlying implementation is a hack.

Incidentally, has figg told you about the gathering he is organising for people interested in programming languages?

[andrewducker]

Just looked a Python example to see how it picks it up, and I have to say I don't like it much - largely because everything we do here is statically typed, with nice names attached to it. Losing that doesn't seem worthwhile.

[martling.livejournal.com]

Oh, sure, it's still Python and therefore a non-confidence-inspiring dynamically typed mess. But the basic principle of tuples as a core part of the type system could be added to to any language - it's just sadly pretty rare outside of functional languages.

If you had them in a statically typed C-like language you could do this:

(int month, int day) GetMonthAndDay(DateTime inputDate) {
    return (inputDate.getMonth(), inputDate.getDay());
}

And then call like this:

(int month, int day) = GetMonthAndDay(date);

Note that as first-class types, tuples would also be usable for input parameters, variables, etc.

(int month, int day) month_and_day;
month_and_day = GetMonthAndDay(date);
int day = month_and_day[1]; // address like arrays.
int month = month_and_day.month; // or like structs, if contents named
 birthdays = GetBirthdays(month_and_day);

[andrewducker]

Which makes them basically methodless classes - except that you can only access the items in them by order, not by name.

To put it mildly - ick!

[martling.livejournal.com]

I don't see any reason why the tuple members couldn't be accessed by name, if names were given for them where the tuple was declared. I suggested this in the the penultimate line above.

The function in that style:

(int month, int day) GetMonthAndDay(DateTime inputDate) {
    return (month = inputDate.getMonth(), day = inputDate.getDay());
}

I'd think of them rather as anonymous C-style structures than as classes - there's nothing specifically object-oriented here.

[andrewducker]

Aaah, sorry. No brain today (dashing in circles fixing things).

That's more useful, definitely. And would do what I want.

Sold!

Now, someone needs to get on the phone to the C# boys and tell them that their anonymous classes need to work better so that they can be used this way!

[meihua.livejournal.com]

I guess I always lean towards the idea of working with nice classes.

DateTime MyDateTime = New DateTime(inputDate)
MyMonth = MyDateTime.Month
MyDay = MyDateTime.Day

[bracknellexile.livejournal.com]

That's the way I'd do it too.

I'll take the flexibility of being able to add properties/methods to a class (and not break existing calling-code when the class is expanded) any day, despite the extra work required to create the class.

[andrewducker]

Not much use if the call you're making takes twenty seconds to return....

[andrewducker]

Not much use if the call to get data can take 20-odd seconds and you don't want to constantly attach both bits of information to each other.

[call-waiting.livejournal.com]

I haven't paid much attention to C# etc, but in C itself it's possible to disambiguate input-only from output parameters in the language with the use of const qualifiers for read-only parameters. Perhaps the Javaish languages make this sort of thing harder.

It's a class of problem, though, that can be easily dealt with as a coding standards issue. So long as there's some clear standard for how input/output parameters are indicated, and that standard is followed (with the help of linting tools).

It's also possible to partially solve the "I need another class for a single return type" problem in C with a macro hack to give the equivalent of anonymous tuple types, which is sometimes handy.

[andrewducker]

The examples I give about with "out" work in C#.

[call-waiting.livejournal.com]

Ah, excellent! Then what you need is a coding standard which states something like: a function with more than one output will have type void and will pass back those outputs by output parameters. I'd still make the argument that for single outputs, a return value is far clearer than an out parameter, so it's a worthwhile language feature. It's just a case of having the authority to enforce good practice ;)

[andrewducker]

Yup - I think I tend to agree.

Of course, if you have 50 methods that all do very similar things (go off and call a business service) and half of them use return values while the other half use outs then it gets confusing. Which is pretty much where my thinking started.

I'll break out the stick when I get into the office tomorrow :->

[drainboy.livejournal.com]

I hate long parameter lists, they end up as a jumble of variable names, where you have to constantly look up ordering to get the functionality you want.

I'm almost tempted to say have one input parameter and one output parameter, where both of those parameters are a list of named variables. You could still deal with default variable values (if your flavour of C has them) in the header file (if your flavour of C has them) and you could still call f(g()) because the output named parameter list of g would contain the input parameter list of f.

Though I'm sure this would get messy as you'd have to then remember the actual names of all the named parameters you wanted to pass.

This might also be more difficult to optimise in terms of putting parameters into registers, though I'm sure compiler writers would find a way (maybe by having JIT recompilation based on code use like C# etc.)

And I'm sure you can do this in Lua already.

[andrewducker]

I hate long parameter lists, they end up as a jumble of variable names, where you have to constantly look up ordering to get the functionality you want.

Which is where intellisense comes in handy. Can't remember the last time I had to look up a method call.

Lists of parameters would lose you strong typing. And I'm _so_ not giving that up.

[drainboy.livejournal.com]

I'm not so convinced they would. You could act like it's a bag of variables, whilst still checking at compile time that all the variables were of the correct type.

Obviously you're right about intellisense, though it's not as good in C++ as in C# (or maybe MSDev 2005 isn't as hot as 2008).

A bag of input parameters would mean you'd no longer have to put all the default variables at the end and fill them in explicitly if you merely wanted the last variable to be a non-default value.

[andrewducker]

C#4.0 has optional/named variable support. You can look forward to that.

And C# is entirely strongly typed - which makes intellisense a lot easier. I believe C++ has issues with that.

[drainboy.livejournal.com]

Actually, thinking about it, whilst you could guarantee the types of the input variables, you might not be sure what you were getting out of the function, so g(f()) might be difficult to strongly type, unless you had default named outputs.

Which starts to get overly complex and doesn't sound worth it :)

[figg.livejournal.com]

Named paramaters are kinda neat, and a little better than passing a list.

[channelpenguin.livejournal.com]

I tend to solve this (for more than, say 2 or 3 out params) by making the return value specific type (object, struct).

[andrewducker]

Which means, in this case, creating 80-odd classes that would exist for no purpose but to bind together two variables for a single return. Seems a bit over the top.

[call-waiting.livejournal.com]

To be honest, that sounds like exactly the sort of problem that generics should be able to solve trivially, and I'm rather puzzled.

It should surely be possible to do something like

class pair<T,U> {
  T fst; U snd; }
pair<int,int> getMonthAndDay(DateTime...);
...
pair<int,int> res = getMonthAndDay(dt);

If something like this isn't possible, then there's something deeply wrong with their generics implementation.

[andrewducker]

That's a perfectly good solution, except that you've just lost any nice naming attached to the objects. In the case above the name of the method makes it nice and clear, but that's not going to always be the case, at least not without some very long clumsy method names.