{"id":127,"date":"2010-08-15T15:54:11","date_gmt":"2010-08-15T14:54:11","guid":{"rendered":"https:\/\/rwec.co.uk\/blog\/?p=127"},"modified":"2010-08-15T15:59:56","modified_gmt":"2010-08-15T14:59:56","slug":"object-references-are-confusing","status":"publish","type":"post","link":"https:\/\/rwec.co.uk\/blog\/2010\/08\/object-references-are-confusing\/","title":{"rendered":"Why object references are confusing, and what to do about it"},"content":{"rendered":"

A recent blog post from my old friend Phil<\/a> ((well, vaguely recent: I really should get with this whole RSS thing!)) discussed some of the gotchas of parameter passing in object-oriented languages – or I suppose specifically in partially<\/em> OO languages, since the problem in this case was a combination of objects and structs in C#.<\/p>\n

It seems to me there is a genuine problem here, beyond programmer fallibility – the old distinction between “pass by value” and “pass by reference” is no longer a useful distinction in such languages, and someone needs to design something better.<\/p>\n

<\/p>\n

To re-summarise, the problem is that in a lot of languages, variables that we call “objects” are actually always “object references”, so a parameter “passed by value” – or even referenced from a non-object structure that was passed by value – is not copied, and can still cause changes to the original instance of the object. <\/p>\n

This can be extremely confusing – I remember similar confusion in Java, where int, float, boolean, and char are basic types, but Strings are objects, so every time you pass a String into a function, that function might accidentally edit the original string. ((Although you’re not supposed to modify String objects anyway, because they’re implemented in some weird way that’s not optimised for manipulation, so you’re supposed to use a different class for that, or something…)) This really highlights the arbitrary distinction underlying the “object reference” model: it’s perfectly reasonable to argue that a string is a complex type, and in C you would use an explicit reference; but in, say, PHP, assigning an existing string to a new variable will copy the contents of that string<\/em> – the underlying mechanics are part of the abstraction of the language.<\/p>\n

Now the reason for the distinction is, I presume, that cloning an object is not always trivial – its internal state may be tied to some outside resource, or require some manual allocation, or just be fundamentally a singleton. So the problem is that objects have to share languages with “POD<\/abbr>” types, like integers, which are much simpler to manipulate as raw data. Purely OO languages, where everything is an object – take Javascript, for instance – don’t have this problem; but they have the opposite problem: they can’t pass by value for any<\/em> type!<\/p>\n

Before I go on, let me admit that I find references confusing at the best of times. I’ve done very little programming in C, but I note that at least there the level of indirection is constantly visible, even if you do end up with rather a lot of it – “pointer to a pointer to a pointer to a char” and so on. In PHP, the =&<\/code> operator makes a variable a reference to another variable, but what does that actually mean? If I set $foo =& $bar<\/code>, what happens if I then say $bar =& $baz<\/code>, or unset($bar)<\/code>? The answers will be entirely logical, I’m sure, but it can be pretty hard to keep track of what a particular assignment is actually assigning to<\/em>. You can even subvert a function’s calling convention by passing in a reference to a non-reference parameter – the de-referencing is implicit, so the function unknowingly modifies the caller’s variable. ((e.g. <\/p>\n

\r\nfunction foo($value)\r\n{\r\n      $value++;\r\n      return $value;\r\n}\r\n$a = 1; foo($a); echo $a; \/\/ 1\r\n$b = 1; foo(&$b); echo $b; \/\/ 2!\r\n<\/pre>\n
))<\/p>\n
An interesting question to look at is why you should be able to write to parameters that have been passed by value at all<\/em>, and Pascal and its descendants let you define “const parameters” which make such modification illegal. This actually allows the compiler to make some hefty optimisations<\/a>, although as soon as you start passing object references, it too becomes much less useful – you can still make calls that modify the underlying object instance, you just can’t assign a brand new instance over the top of the variable.<\/p>\n
Solution<\/h2>\n
OK, I’m not going to say I’ve suddenly invented a language construct that will revolutionise programming, but I wonder if something can be done to make this all a bit less obscure. The ability to recursively clone an object is hard enough, let alone the ability to recursively but context-sensitively mark it as immutable, so this may all be impractical. OTOH<\/abbr>, some of this is probably already available in current OOP languages, but it’s consistency<\/em> I’m after.<\/p>\n
    \n
  1. Make all types objects, and all variables object references – even if the underlying language optimises, say, an int object by only introducing indirection in memory when more than one reference is needed.<\/li>\n
  2. Include a simple method for duplicating object instances, like PHP’s clone<\/code> operator, so that assign-by-value becomes something like $x = clone $y;<\/code>.<\/li>\n
  3. Allow classes ((or the equivalent in a prototype-based language, etc)) to define custom clone mechanics, or – crucially – declare that they are “uncloneable”.<\/li>\n
  4. Force additional levels of indirection to be explicit – that is, a variable of type “reference to String” cannot be passed to a function expecting a variable of type “String” without explicit de-referencing.<\/li>\n
  5. Most importantly, replace the out-dated “pass by value” vs “pass by reference” convention with something more appropriate for such a variable system:\n
      \n
    • “reference” parameters<\/strong> – the most common option; modifications to the object will affect the original instance, and<\/em> assignments to the variable will overwrite the original object reference<\/li>\n
    • “clone” parameters<\/strong> – effectively a true pass by value: the object is cloned automatically, and only the clone is visible to the called function; passing an object that cannot be cloned is illegal<\/li>\n
    • “const” parameters<\/strong> – the local variable is read-only (you can’t overwrite it to reference a different object instance) and<\/em> the underlying object is marked immutable, recursively, within that scope<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
      A recent blog post from my old friend Phil ((well, vaguely recent: I really should get with this whole RSS thing!)) discussed some of the gotchas of parameter passing in object-oriented languages – or I suppose specifically in partially OO languages, since the problem in this case was a combination of objects and structs in […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[99,95,93,92,94,90,96,97,91,98],"class_list":["post-127","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-const","tag-language-design","tag-objects","tag-oop","tag-parameters","tag-programming","tag-reference","tag-references","tag-types","tag-value","post-preview"],"_links":{"self":[{"href":"https:\/\/rwec.co.uk\/blog\/wp-json\/wp\/v2\/posts\/127","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rwec.co.uk\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rwec.co.uk\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rwec.co.uk\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rwec.co.uk\/blog\/wp-json\/wp\/v2\/comments?post=127"}],"version-history":[{"count":6,"href":"https:\/\/rwec.co.uk\/blog\/wp-json\/wp\/v2\/posts\/127\/revisions"}],"predecessor-version":[{"id":133,"href":"https:\/\/rwec.co.uk\/blog\/wp-json\/wp\/v2\/posts\/127\/revisions\/133"}],"wp:attachment":[{"href":"https:\/\/rwec.co.uk\/blog\/wp-json\/wp\/v2\/media?parent=127"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rwec.co.uk\/blog\/wp-json\/wp\/v2\/categories?post=127"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rwec.co.uk\/blog\/wp-json\/wp\/v2\/tags?post=127"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}