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
Implementation of a dynamic prototype-based programming in Red #3064
base: master
Are you sure you want to change the base?
Conversation
Added symbol '_proto'
Implement prototype-based programming with property-shared concepts (only yet variables = properties)
Implement property-share in prototype-based programming. Only for properties, method yet not implemented
@ejtizado, this is really cool work. Unfortunately, it may not be a good fit for Core Red at this time, and now has conflicts which would need resolving. I'd like to close this, but don't want to lose the link to your work, until we have modules and a better way to consider it in the future. |
I kept hoping we'd make time to give this it's proper due, but our planned roadmap is already quite a challenge, and I'm not sure when we'll get to this. Feel free to bring it up in chat on Gitter, and solicit feedback from others. Again, I really don't want to see this just disappear. |
1ec06cd
to
7218fb4
Compare
Red implement a prototype-based programming (value-share), i.e., the clones will be created from a prototype, but after creation they stand on their own feet (creation-time sharing).
See the paper of this link.
This addon of Red tries to implement a dynamic prototype-based programming (property-share), transparent to users and usual rules of Red.
This implementation following the concepts of the Self implementation of the object oriented programming language. Then, it uses objects and slots concept, i.e., it does not distinct variables from methods to be more flexible. Thus it also follow the philosophy of Red.
However, to explain the implementation, the difference between variables (properties) and methods (functions) is necessary.
Properties (variables)
Delegation (1): to share the value of a property
The delegation is clean and follow the rules of Red. The only difference is the slot
_proto
(or any other name decided by the main contributors of Red as_is
) to clone an object when we declare as prototype-based object from any otherobject!
(with or whithout prototype).It is not necessary the slot
_proto
to clone a siblind prototype following the rules of Red, but copy all other variables of the siblind object, if this conduct is not desirable then the user can use the usual creation of a prototype-based object.CPU cost
The cpu cost of this implementation to other users of
object!
is zero. However, a bad programming conduct could lead to crash the systemTo avoid it, is necessary check
_proto
as a validobject!
. There are two possibilities:Zero cost for object users and high cost for prototype users.
It is possible checking the validity of
_proto
in the delegation process, but the pay for the prototype users is in all delegations (variable access) of a prototype-based object.Cost sharing for all users.
The checking of validity of
_proto
is placed in the creation ofobject!
.I implement this option because the cost for all users is low only when
make
the object. After that, no aditional cost for any users at this moment.Delegation (2): new value of a property
Logically, any object can change the values of their properties but the question is if an object can modify the value of a prototype property or if can add new properties. This feature could be resolve with three mechanisms, from low to high cpu cost:
Objects can modify the slot values of the prototypes but no add new properties.
It is the more easy to implement without any aditional cost to the users. However, I think, this is a very risky option.
Objects can not add or modify properties of theirs prototypes.
This could be the default mechanism when the objects are static after creation. An object only can modify their properties. This idea is nowdays in the background of Red because a
extend
function is not posible to add properties to the objects.Objects can override properties of the prototypes, creating property if it is necessary.
An object can add properties presents in their prototypes but can no add new properties (when
extend
will be implemented in Red, they will can althought the implementation is easy!).I implement this last option because is safe, flexible and the cpu cost is the same as the previous option.
Remove properties
In this moment Red does not implement a function to remove slots of an object. Then, it is not implemented but when it will be implemented to
object!
, it could be used in prototype-based programming with any change.Methods (functions)
To be implemented