Cypress-Structure versus Cypress-Definitions?

[bpieber]

What is the difference between the Structure and definition classes? What are the respective responsibilities?
E.g. there seems to be a lot of overlap between CypressClassStructure and CypressClassDefinition. What is the rationale here?

[dalehenrich]

I've separated the Structures from the Definitions, because I don't want to "mix the streams". Certainly there are similarities between CypressClassStructure and CypressClassDefinition, but there are differences, too. It is the differences that are important to me ...

The Definition structure has a single job in life: model the native Smalltalk environment and support the loading and unloading of the Smalltalk elements. I don't expect the CypressDefinitions to change over time.

The Structure classes will morph over time to match the current thinking of how we want to model package structure on disk.
The Readers/Writers operate on class structure and will also change over time ...

Presumably the Structure implementation will be the only part of Cypress that will be the same in all dialects ... the definitions will definitely change and the reader/writers will definitely change ...

Finally at this stage of the project I want the freedom that the separate class hierarchys gives me. For Amber Smalltalk, the Structure and Definition classes are present. In the Pharo server for Amber, the Structure and Reader/Writer classes are present ... Cuis is the first dialect in which all three hierarchies are present ... I'll also want to write a native Cypress port for Pharo as well ... which begs the question of how I will be able to use Pharo as a server for Amber and Amber structure as well as provide native Cypress support for Amber ...

So explicitly separating different responsibilities is a convenience that may or may not survive in the long term...

[dalehenrich]

Another point is that the Cypress classes are being written (from my perspective) as a reference implementation. I would have not problem with you guys taking the reference implementation and casting it in a form that you'd like to use within CUIS ... FileTree is the Monticelo variant and STIG is the VW variant and they don't share code ... the underlying disk format is important.

I started the port to CUIS mainly to fill out the pieces of the reference implementation that weren't covered by the Amber work and to get my feet wet in CUIS ...