search

instantiations / tonel-vast

Tonel file format writer and reader implementation for VA Smalltalk
MIT License
9 stars 3 forks source link

Pros and Cons of package properties #27

Open dalehenrich opened 4 years ago

dalehenrich commented 4 years ago

Now that we are discussing the integration of the Rowan disk structure into tonel-vast support. I would like to discuss the pros and cons of the use of the package properties:

In Rowan V1.2, we have package-specific properties, but instead of embedding the properties in the package.st file, I chose to put the package-specific properties into a configuration file located in a rowan/configs directory.

For Rowan V2.0, I have continued to follow the same model with package-specific properties located in a rowan/v2/components directory. The default values for the package-specific properties are located in a load specification. The defaults are used when the package-specific property is not explicitly declared.

I don't have the option of changing disk format for V1.2, but for V2.0 I do have the option of changing the disk format and I have been considering moving the package-specific properties into the packages.st file, but there are some cons to doing so and these cons are worth sharing with you, since I think they have the same impact on VAST.

The primary con to adding package specific properties is the impact on ones ability to seamlessly add Rowan support to existing git-based projects like Seaside. If the on-disk format of a package is written by Rowan with additional package properties, existing users of those packages (Pharo, Squeak, and GLASS) will not preserve the additional package properties and it would be impossible to use Rowan with any existing project until Pharo, Squeak, and GLASS have adopted the Rowan package format. Seaside uses filetree format, but by isolating the package-specific properties in the rowan directory structure it becomes practical for Rowan to support both filetree and tonel based projects --- seamlessly.

If VAST moved their package-specific properties into the components files, it would become possible for VAST to support the reading and writing of filetree format and make it possible for VAST users to use the Seaside project directly without waiting for Seaside to convert to tonel. If VAST leaves the package-specific properties in the package.st file, then Rowan could/should move it's package-specific properties into the package.st file as well ...

This argument works the other way as well. If VAST chooses to use the Rowan component structure, it is less necessary to have to change the existing package disk format, since there are alternate locations to store the VAST package meta data.

With that said I am not wedded to the existing component file format and I am very open to different component structure suggestions.

Sooo, I'm raising of the issue here for discusion ... I don't want to make a unilateral decision one way or the other and I think that a joint discussion is warranted (@kurtkilpela and @martinmcclure please chime in).

dalehenrich commented 4 years ago

As I've thought about this there is a use case where two different users of the same package may want to use different package-specific properties.

For GemStone/Rowan case that would mean two different users would want the classes in the package loaded into different symbol dictionaries ... this would necessitate the creation of a separate component with today's component implementations ... It would be legal to have two separate top-level/loadable components that specify different symbol dictionaries for the packages ...

For VAST this would happen if two different configmaps wanted to use the same package in a different application (am I using the correct terminology)? I assume that this would entail needing to specify different prerequisites/parents/subApplications for the shared package?