Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow functional update in initializer #5223

Closed
vicuna opened this issue Feb 10, 2011 · 4 comments
Closed

Allow functional update in initializer #5223

vicuna opened this issue Feb 10, 2011 · 4 comments

Comments

@vicuna
Copy link

vicuna commented Feb 10, 2011

Original bug ID: 5223
Reporter: khooyp
Assigned to: @garrigue
Status: closed (set by @garrigue on 2016-12-13T00:27:20Z)
Resolution: won't fix
Priority: normal
Severity: feature
Version: 3.12.0
Category: ~DO NOT USE (was: OCaml general)

Bug description

Is 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 ... >}
initializer
self#foo
end

@vicuna
Copy link
Author

vicuna commented Feb 10, 2011

Comment author: @garrigue

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...

@vicuna
Copy link
Author

vicuna commented Feb 11, 2011

Comment author: khooyp

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.

@vicuna
Copy link
Author

vicuna commented Dec 12, 2016

Comment author: @mshinwell

@garrigue: Are we interested in this proposal or shall we close the issue? It's been five years now...

@vicuna
Copy link
Author

vicuna commented Dec 13, 2016

Comment author: @garrigue

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants