Hey, After spending some though on deepfreezing objects (pickling in python and serializing in java) and in the course of the discussion about deep copies, I came to the opinion that there should be no object holding the lobby as parent except for the world. It is like importing everything in any other language. Like doing import * or include<*.h>. In self a parent is seen as a part of the object that can be reused. But needs an object all prototypes at all time? And should all the prototypes really be globals :)? So that we not only reference the objects we really need leads to the problem that we don't know its true foundation. We could easily deep copy it when it only referenced them, because the object graph would contain exactly the objects it needed to work in every world, without taking the entire world with it. It wouldn't know about the others anyway.
I like the way mixins are used, you have to explicitly demand them. Other objects and especially prototypes should be handled the same way. You reference them explicitly only if you need them, say in a "import*" parent object (if you don't want them to mess your object) and not via the lobby by name. Since slots are created in the context of the lobby you could easily add a slot and do "gasTank = gasTank"
Any thoughts :D?
Cheers Jan
It depends on what you are doing. Larger projects can benefit from more control over what's imported, and you can do that if you like. For exploratory programming (see Beau Sheill's (sp?) paper), it's nice to just have everything at your fingertips. You seem to hold some assumptions that you do not always articulate.
- David
On Dec 27, 2010, at 1:49 PM, Jan-Paul Bultmann wrote:
Hey, After spending some though on deepfreezing objects (pickling in python and serializing in java) and in the course of the discussion about deep copies, I came to the opinion that there should be no object holding the lobby as parent except for the world. It is like importing everything in any other language. Like doing import * or include<*.h>. In self a parent is seen as a part of the object that can be reused. But needs an object all prototypes at all time? And should all the prototypes really be globals :)? So that we not only reference the objects we really need leads to the problem that we don't know its true foundation. We could easily deep copy it when it only referenced them, because the object graph would contain exactly the objects it needed to work in every world, without taking the entire world with it. It wouldn't know about the others anyway.
I like the way mixins are used, you have to explicitly demand them. Other objects and especially prototypes should be handled the same way. You reference them explicitly only if you need them, say in a "import*" parent object (if you don't want them to mess your object) and not via the lobby by name. Since slots are created in the context of the lobby you could easily add a slot and do "gasTank = gasTank"
Any thoughts :D?
Cheers Jan
On 28.12.2010, at 03:20, ungar@mac.com wrote:
It depends on what you are doing. Larger projects can benefit from more control over what's imported, and you can do that if you like.
For exploratory programming (see Beau Sheill's (sp?) paper), it's nice to just have everything at your fingertips.
Sadly I will only be able to get the paper next year.
You seem to hold some assumptions that you do not always articulate.
That needs a bit more explanation :)
Cheers Jan
- David
On Dec 27, 2010, at 1:49 PM, Jan-Paul Bultmann wrote:
Hey, After spending some though on deepfreezing objects (pickling in python and serializing in java) and in the course of the discussion about deep copies, I came to the opinion that there should be no object holding the lobby as parent except for the world. It is like importing everything in any other language. Like doing import * or include<*.h>. In self a parent is seen as a part of the object that can be reused. But needs an object all prototypes at all time? And should all the prototypes really be globals :)? So that we not only reference the objects we really need leads to the problem that we don't know its true foundation. We could easily deep copy it when it only referenced them, because the object graph would contain exactly the objects it needed to work in every world, without taking the entire world with it. It wouldn't know about the others anyway.
I like the way mixins are used, you have to explicitly demand them. Other objects and especially prototypes should be handled the same way. You reference them explicitly only if you need them, say in a "import*" parent object (if you don't want them to mess your object) and not via the lobby by name. Since slots are created in the context of the lobby you could easily add a slot and do "gasTank = gasTank"
Any thoughts :D?
Cheers Jan
self-interest@lists.selflanguage.org
-
Jan-Paul Bultmann -
ungar＠mac.com