Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005223OCaml-OCaml generalpublic2011-02-10 19:472016-12-13 01:27
Assigned Togarrigue 
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version3.12.0 
Target VersionFixed in Version 
Summary0005223: Allow functional update in initializer
DescriptionIs it possible to allow functional updates "{< ... >}" in object initializers (or another keyword for such cases)? I.e., allow initializers to return objects of self type? Initializers are quite useful for sharing code between constructors and methods, but it can't be used with functional objects (without making instance variables mutable).

For example:

class c = object (self)
    val x = 0
    method foo = {< x = ... some complex operation ... >}

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
garrigue (manager)
2011-02-11 00:57

You raise an interesting question.
The main difficulty I see is that it would require a change in initializer semantics:
currently an initializer receives self and returns nothing, and you suggest that it should
return a new self. It seems hard to make this compatible with the current behaviour,
except by discriminating on the return type in a dirty way.

Note that you can already change the internal state of an object when inheriting, just
by overwriting it. What is missing is the ability to access the previous state. It could be
possible, because the system already protects against accessing variables when a value field
with the same name is defined.
Consider this program:

class c = object val x = 1 method get = x end
class d x = object inherit c val x = x+1 end

Currently it is refused:
Error: The instance variable x
cannot be accessed from the definition of another instance variable

Allowing it would mean that the field definition in c overrides the x from
d's constructor. I've heard that this kind of situation is allowed in Scala, but
very confusing, so I'm not sure allowing it would be a good idea...
khooyp (reporter)
2011-02-11 01:45

I wouldn't mind a different syntax to discriminate unit initializers and self initializers, say initializer vs. initializer!.

Allowing instance variable definitions to refer to previous definitions doesn't quite cover the use case I described - sharing code in methods - since the definition cannot refer to self (unless self is treated as an instance variable too?). To give a more concrete example, a set class might be defined as:

class ['elt] set init_list = object (self : 'self)
    method add x : 'self = ...
        List.fold_left (fun set x -> set#add x) self init_list

Furthermore, initializer currently allow mutable objects to be updated, which can already lead to the situation you describe (depending on the order of inherit/initializer). While it may potentially be confusing, but it's also quite convenient. It would be nice to give functional objects similar capabilities.
shinwell (developer)
2016-12-12 17:02

@garrigue: Are we interested in this proposal or shall we close the issue? It's been five years now...
garrigue (manager)
2016-12-13 01:27

This is asking for a new feature, whose semantics is not so easy to define.
The priority of adding new features to the object system being low, I close this PR.

- Issue History
Date Modified Username Field Change
2011-02-10 19:47 khooyp New Issue
2011-02-11 00:42 garrigue Status new => assigned
2011-02-11 00:42 garrigue Assigned To => garrigue
2011-02-11 00:57 garrigue Note Added: 0005800
2011-02-11 01:45 khooyp Note Added: 0005801
2016-12-12 17:02 shinwell Note Added: 0016973
2016-12-13 01:27 garrigue Note Added: 0016985
2016-12-13 01:27 garrigue Status assigned => closed
2016-12-13 01:27 garrigue Resolution open => won't fix
2017-02-23 16:36 doligez Category OCaml general => -OCaml general

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker