andrewducker (
andrewducker) wrote2009-04-09 03:38 pm
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Musings
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.
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.
no subject
procedure GetMonthAndDay(inputDate: in DateTime; month: out Integer; day: out Integer) is
begin
-- do stuff here
end GetMonthAndDay;
(no subject)
(no subject)
no subject
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.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
DateTime MyDateTime = New DateTime(inputDate)
MyMonth = MyDateTime.Month
MyDay = MyDateTime.Day
(no subject)
(no subject)
(no subject)
no subject
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.
(no subject)
(no subject)
(no subject)
no subject
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.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)
(no subject)