filetree

Hi,

On 11/11/12 09:50, jtuchel wrote:

> Hi Dale and others,
>
> is this the best group to discuss ideas on file tree? If not, where
> should I post to?
>
> Here's what I'd like to discuss:
> I was looking at a file tree repository on github (STON, but that's not
> important) in order to see whether it would be a good idea to look into
> porting filetree to VA Smalltalk. I found a few issues that could be a
> hinderance to use filetree in VAST, which would be a real pity. Filetree
> is a very fine piece of engineering and I am very positive about its
> usefulness in bringing Smalltalk dialects closer together as well as
> moving smalltalk code into the mainstream.
>
> First, it seems filetree assumes a method resides in exactly one
> category. This is not the case in VAST. Even class extension methods can
> live in any number of categories. So in order to use filetree in VAST as
> well, it'd have to be extended to use multiple categories for methods. I
> don't think this is hard or problematic for Pharo/Squeak/Gemstone, but
> we should do it in a way so that all dialects speak the same "language".

Dale will correct me if I'm wrong:

The idea is that Cypress [1] (filetree is an implementation of Cypress
in Squeak/Pharo) does not define "common" format covering all
features of all possible smalltalks. This is not possible, there were
so many attempts -- all failed to be adopted. Instead, Cypress says
this is minimal set of what you should support and you're free to add
any kind of data you want for your purpose. Others must tolerate their
presence (but are free to ignore them). See the "Cypress specification"

https://github.com/CampSmalltalk/Cypress/wiki

(takes no more than 3 min to read whole spec :-)

For example, Smalltalk/X implementation preserves all files it does not
know about and all properties as long as they have a "unknown"
vendor prefix.

So, in your particular case, I would store "the most likely" category
along with the method as Cypress/filetree does and then for each method
add a <method name>.ston with something like

{
   "_vast_categories" : [ "c1" , "c2" , "..." ]
}

During load, you are free to ignore what is in the method.st and use
only "_vast_categories" (perhaps using method.st's category as default
when no vast-specific property is found).

That's correct behavior with respect of Cypress (filetree) "spec".


>
> Secondly, I wonder if it would be of any help if a filetree package had
> some meta-information on what Smalltalk environment (including the exact
> VM and image versions) the package comes from. This could help in later
> stages with adding special porting layers and such to filetree
> importers. Just imagine we collect some rewrite rules that help automate
> importing VAST code into GemStone or Pharp Code into Smalltalk/X and
> such and use the meta information to automate at least some portion of
> the parting efforts.

Well, you may "teach" your implementation to understand other vendor's
specific data (they should be prefixed if in common property files).

I'm personally fine with extra package-level propery
"_cypress_generated_by" : "VAST". Even now you can generate it
(and still be "spec" compliant) and other will adopt it soon, if it show
up to be useful :-)

>
> Third, I wonder if the idea for config management with filetree is to
>   use ConfigurationOfxxx classes in their own packages to allow complex
> exports/imports of whole configurations - am I right? If that s the case
> (and it seems that could be accomplished quite nicely), I think we need
> to invest quite some energy to think about adapting between
> Configurations and Config Maps. Or maybe we just need to implement
> Configurations as well in VAST and build some helpers to create a
> Configuration class from Config Maps
>

I can't really tell :-)

> Fourth: is anybody working on filetree for VAST already?
>

Dunno.

Cheers, Jan