[% setvar title Positional Return Lists Considered Harmful %]

This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/

TITLE

Positional Return Lists Considered Harmful

VERSION

  Maintainer: Jarkko Hietaniemi <jhi@iki.fi>
  Date: 5 Aug 2000
  Mailing List: perl6-language@perl.org
  Number: 37
  Version: 2
  Status: Developing

ABSTRACT

Perl has traditionally returned from various functions long (>2) lists of values. Some traditions are simply bad.

DESCRIPTION

Functions like stat() and get*ent() return long lists of mysterious values. The implementation is assumedly easy: just push some values out of C structs into the Perl return stack.

Wrong. And once more, wrong.

Firstly, who can remember which one of the stat() return values was the atime or which is the 4th return value of localtime()? The perlfunc gmtime/localtime documentation makes this difficulty painfully obvious by having to list the indices alongside the values.

Secondly, the current solution is seriously non-extensible. One cannot easily add new return values to the APIs because someone may be expecting an exact number of return values, or someone may be accessing the values by position from the end of the list Obsoleting values (or marking them as non-applicable to the current platform) has to be done by for examples returning undef.

IMPLEMENTATION

The solution is simple: return hashes instead of lists. Yes, one still has to know how the fields are named, so the proposed solution is still not perfect.

THE AFFECTED FUNCTIONS

	caller [1]
	getgrent
	getgrnam
	getgrgid
	gethostbyaddr
	gethostbyname
	gethostent
        getnetbyaddr
	getnetbyname
	getnetent
	getprotobyname
	getprotobynumber
	getprotoent
	getpwent
	getpwnam
	getpwuid
	getservbyname
	getservbyport
	getservent
	gmtime
	localtime
	stat
	

[1] I guess the whole semantics and functionality of caller() is severely up for grabs for Perl6.

For the get*() mafia, it is also debatable whether aping the C interface is a good thing and worth preserving as such at all. The preferred interface might be tied hashes. This interface might also more naturally support non-POSIX operating systems with their own native semantics, or POSIX operating systems with extended semantics like higher security user databases.

REFERENCES

  perlfunc
  File::stat
  User::grent
  User::pwent