0005223: Allow functional update in initializer

Notes
(0005800) 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...

(0005801) 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 = ... initializer List.fold_left (fun set x -> set#add x) self init_list end 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.

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

Relationships