Z
zuzu
anyone interested in this? or have information about how this applies
to ruby as "pure OO"?
http://c2.com/cgi/wiki?ObjectCapabilityModel
Object Capability Model
To avoid confusion, ObjectCapabilityModel is the new name for the
original capability model, as represented originally by
DennisAndVanHorn and other early capability operating systems,
ProtectionInProgrammingLanguages, and the various ActorsLanguages.
This model can be implemented in a number of different ways:
ObjectCapabilityOperatingSystem (DennisAndVanHorn, HydraOs, CapOs,
MachOs?, KeyKos, ErosOs)
ObjectCapabilityLanguage (ActorsLanguage,
ProtectionInProgrammingLanguages, W7 (DoubleYouSevenLanguage),
JouleLanguage, E (EeLanguage), possibly OzLanguage)
ObjectCapabilityHardware? (IntelFourThreeTwo?, IbmSystemThirtyeight?)
The pure ObjectOrientedProgramming model and the ActorsModel of
computation is essentially lambda calculus + local side effects +
method dispatch. The SchemeLanguage, the MlLanguage, and the
PiCalculus are lambda calculus + local side effects. As explained in
OdeToTheGranovetterDiagram and ParadigmRegained, to get from any of
these (or from ConcurrentLogicProgramming?) to the
ObjectCapabilityModel, you don't need to add anything, and you don't
need to remove anything. Essentially all you need to do guarantee that
sources of causality outside these models (such as mutable static
state or static native devices) are not made available to computation
by other means. With these guarantees, the object reference graph
becomes the access graph. (The access graph is just a better way to
visualize Lampson's access matrix.)
Often, local object capability systems are connected by a
cryptographic capability protocol. A distributed capability protocol
by itself cannot be more than a PasswordCapabilityModel. But when used
to connect local object capability systems, we say the result
implements the DistributedObjectCapabilityModel.
For programming style guidelines specific to the
ObjectCapabilityModel, see CapabilityOrientedProgramming.
Unlike the other CapabilitySecurityModels, the object-capability model
isn't a security model to be bolted on to some other model of
computation. Rather, it is a model of computation that's inherently
modular and secure. It dates from when the study of modularity and
abstraction mechanisms had not yet become a separate discipline from
the study of security. DennisAndVanHorn understood that good
modularity and abstraction mechanisms should be good security
mechanisms, and sought to solve the whole problem with one unified set
of mechanisms.
to ruby as "pure OO"?
http://c2.com/cgi/wiki?ObjectCapabilityModel
Object Capability Model
To avoid confusion, ObjectCapabilityModel is the new name for the
original capability model, as represented originally by
DennisAndVanHorn and other early capability operating systems,
ProtectionInProgrammingLanguages, and the various ActorsLanguages.
This model can be implemented in a number of different ways:
ObjectCapabilityOperatingSystem (DennisAndVanHorn, HydraOs, CapOs,
MachOs?, KeyKos, ErosOs)
ObjectCapabilityLanguage (ActorsLanguage,
ProtectionInProgrammingLanguages, W7 (DoubleYouSevenLanguage),
JouleLanguage, E (EeLanguage), possibly OzLanguage)
ObjectCapabilityHardware? (IntelFourThreeTwo?, IbmSystemThirtyeight?)
The pure ObjectOrientedProgramming model and the ActorsModel of
computation is essentially lambda calculus + local side effects +
method dispatch. The SchemeLanguage, the MlLanguage, and the
PiCalculus are lambda calculus + local side effects. As explained in
OdeToTheGranovetterDiagram and ParadigmRegained, to get from any of
these (or from ConcurrentLogicProgramming?) to the
ObjectCapabilityModel, you don't need to add anything, and you don't
need to remove anything. Essentially all you need to do guarantee that
sources of causality outside these models (such as mutable static
state or static native devices) are not made available to computation
by other means. With these guarantees, the object reference graph
becomes the access graph. (The access graph is just a better way to
visualize Lampson's access matrix.)
Often, local object capability systems are connected by a
cryptographic capability protocol. A distributed capability protocol
by itself cannot be more than a PasswordCapabilityModel. But when used
to connect local object capability systems, we say the result
implements the DistributedObjectCapabilityModel.
For programming style guidelines specific to the
ObjectCapabilityModel, see CapabilityOrientedProgramming.
Unlike the other CapabilitySecurityModels, the object-capability model
isn't a security model to be bolted on to some other model of
computation. Rather, it is a model of computation that's inherently
modular and secure. It dates from when the study of modularity and
abstraction mechanisms had not yet become a separate discipline from
the study of security. DennisAndVanHorn understood that good
modularity and abstraction mechanisms should be good security
mechanisms, and sought to solve the whole problem with one unified set
of mechanisms.