Sam Vilain wrote: > > On Thu, 06 Mar 2003 05:10, Garrett Goebel wrote: > > Several people have mentioned a desire to see Perl6 > > and Parrot facilitate object persistence. Should > > such issues be tackled in Parrot? > > Not necessarily. Just be friendly to object persistence > frameworks by exporting object relationships in a > sensible and consistent manner. It is those relation- > ships that drive the object persistence frameworks, and > implementations of the object structure in various > languages.
"exporting object relationships in a sensible and consistent manner" Sounds like something worthy of more than a passing reference. In the context of parrot, what falls within the scope of a sensible and consistent manner? > The exact semantics and mechanisms of object persistence > are still quite a research topic, so it is not appropriate > yet to select one method as the best. However, I believe > that the concepts of Object, Attribute, Association, > Methods are stable. > > > What does parrot need to facilitate object persistence > > and cross-language OO? Obviously the OMG's UML and > > family of specifications deal with these issues. What > > other practical approaches exist? > > UML does not deal with persistence. It deals with > specifying and modelling objects. When I said "UML and family" I was lumping in Meta-Object Facility (MOF), Common Warehouse Metamodel (CWM), Common Object Request Broker (CORBA), Object Constraint Language (OCL), etc. 10,000+ pages of spine tingling object modeling, persistence, and interchange specifications... Important in itself not just as the provider of a common vocabulary and semantics for programming, but also a helpful sleep aid. MOF nails down Packages, Classes, Associations, Attributes, and Operations. Objects being instances of classes... And while the OMG specs are overkill, there's probably some gems of relevant insight in them. Especially if it is a goal for parrot to allow python code to invoke methods on objects coded in perl. Over on perl6-internals you've been talking about the need for Associations. Is the addition of associations all that's missing from Parrot to support "exporting object relationships in a sensible and consistent manner"? What are the traps and pitfalls that'll need to be avoided in Parrot's design to make object persistence not just possible but realistically feasible? For example: serializing objects without capturing their associations. Will the absence of associations force us to rely on attributes and convention to serialize an object's associations? I.e., as I thought you were implying, a messy hack that'll come back to haunt us? -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
