Where to put Pharo-compatibility code

1. Where should we put such methods? It is clear that many of these methods do not belong in any of the ported packages, like NeoCSV or STON or whatever. OTOH, Grease is probably also not the right place to do that, or is it?
2. How can we make such a layer grow fast? By this I mean we should make it independent of VAST product cycles. (which is also a counter argument to Grease).
3. How could we make such a beast a community effort? I mean, most of these methods are one to three lines long and chances are that if it's easy to add a method to our new compatibility layer, it will be done by many people and the layer would grow faster

Hi VAST community,

every time I port code from Pharo, I stumble across the same class of code differences all the time.

Apart from curly braces for Array construction, these mostly are shortcut methods in the Collection hierarchy like #join:, #count:, #sum: , #allButFirstDo: and so on. The list is long.

In the beginning, I just rewrote the methods in my VA port of a monticello package, then I realized people in Pharo love these methods as they save a lot of typing. So they are being used very often in code that I want to port to VAST. If you have to change the same pieces of code every time you want to port a monticello package to VAST, this is not practicable. In the end, porting becomes so much work that you don't do it anymore and stick with what you have for as long as you can.

So the next - and possibly much better - alternative would be to add these methods to VAST, so that porting code from Pharo becomes easier every time somebody added such a method.

This brings me to a series of questions:

1. Where should we put such methods? It is clear that many of these methods do not belong in any of the ported packages, like NeoCSV or STON or whatever. OTOH, Grease is probably also not the right place to do that, or is it?
2. How can we make such a layer grow fast? By this I mean we should make it independent of VAST product cycles. (which is also a counter argument to Grease).
3. How could we make such a beast a community effort? I mean, most of these methods are one to three lines long and chances are that if it's easy to add a method to our new compatibility layer, it will be done by many people and the layer would grow faster

As you can probably see, my feelings towards adding stuff to Grease are mixed. Grease's idea is exactly what I am talking about: a portability layer. So it seems to be the perfect place for such methods. OTOH, adding more and more completely unrelated stuff into such a package would turn it into a giant ball of mud.

I think many of these little helper methods should make their way into the product, but am not sure if Instantiations would be willing to do that. And as long as Instantiations cannot ship upgrades independent of full product releases, this would probably be a slow process. 

So what do people think? Should we start another portability layer and maintain it on VASTGoodies? Should we extend grease and look for ways to synchronize the community version of Grease with the one that Instantiations ships with VA?

What does Instantiations think? Do you see a need for extensions to VAST classes to make porting Pharo (and also Squeak) code easier?

I know people are working on Cypress/Filetree for VAST. Is there any idea for this family of problems in Cypress? What layer do they use/make?

I am really interested in opinions from as many people as possible. Porting code from Pharo could be so much easier if we just added these little extensions to VAST.

Joachim

Hi, I am back to this topic.

While I think Richard's suggestion would be the right/best possible thing to do, it also is the one requiring most work and maintenance. So it's very likely it is not going to happen...

So here I am in the middle of an actual problem that I put myself into: yesterday I uploaded VBRegex in a new version to VASTGoodies, because I had this port for a long time now and thought it's time for others to have it available. I was surprised to see I hadn't uploaded a few months ago.

But now I remember why: the first "customer" who wanted to use it, stumbled from one problem to the next:

first, a method was missing that is implemented in Grease (Character class >> newPage). Okay, I could possibly live with declaring Grease a prerequisite for VBRegex.

A few minutes later, he asked where to find Collection>>#contains: . It turns out is a method that comes with Glorp. 

Since I use Seaside and Glorp all the time, this has never been an issue for me, but it sure will be for others. Making Glorp a prerequisite of VBRegex is sure not as acceptable as making Grease a prerequisite of VBRegex.

Now we're in the middle of the trouble: I could probably use Richard's suggestion and move Collection>>#contains: to a subappliction and add a config expression for it. But this is only part of a possible solution: What if somebody loads Glorp after VBRegex? Then They'd get load errors and scratch editions.

What now?

Joachim

Am Samstag, 11. Januar 2014 15:17:26 UTC+1 schrieb [hidden email]:

Hi VAST community,

every time I port code from Pharo, I stumble across the same class of code differences all the time.

Apart from curly braces for Array construction, these mostly are shortcut methods in the Collection hierarchy like #join:, #count:, #sum: , #allButFirstDo: and so on. The list is long.

In the beginning, I just rewrote the methods in my VA port of a monticello package, then I realized people in Pharo love these methods as they save a lot of typing. So they are being used very often in code that I want to port to VAST. If you have to change the same pieces of code every time you want to port a monticello package to VAST, this is not practicable. In the end, porting becomes so much work that you don't do it anymore and stick with what you have for as long as you can.

So the next - and possibly much better - alternative would be to add these methods to VAST, so that porting code from Pharo becomes easier every time somebody added such a method.

This brings me to a series of questions:

1. Where should we put such methods? It is clear that many of these methods do not belong in any of the ported packages, like NeoCSV or STON or whatever. OTOH, Grease is probably also not the right place to do that, or is it?
2. How can we make such a layer grow fast? By this I mean we should make it independent of VAST product cycles. (which is also a counter argument to Grease).
3. How could we make such a beast a community effort? I mean, most of these methods are one to three lines long and chances are that if it's easy to add a method to our new compatibility layer, it will be done by many people and the layer would grow faster

As you can probably see, my feelings towards adding stuff to Grease are mixed. Grease's idea is exactly what I am talking about: a portability layer. So it seems to be the perfect place for such methods. OTOH, adding more and more completely unrelated stuff into such a package would turn it into a giant ball of mud.

I think many of these little helper methods should make their way into the product, but am not sure if Instantiations would be willing to do that. And as long as Instantiations cannot ship upgrades independent of full product releases, this would probably be a slow process. 

So what do people think? Should we start another portability layer and maintain it on VASTGoodies? Should we extend grease and look for ways to synchronize the community version of Grease with the one that Instantiations ships with VA?

What does Instantiations think? Do you see a need for extensions to VAST classes to make porting Pharo (and also Squeak) code easier?

I know people are working on Cypress/Filetree for VAST. Is there any idea for this family of problems in Cypress? What layer do they use/make?

I am really interested in opinions from as many people as possible. Porting code from Pharo could be so much easier if we just added these little extensions to VAST.

Joachim

Hi Joachim,

I don't know how long the list of issues is, but Collection>>#contains: is non-ANSI. You could suggest to the VBRegex project to use the ANSI method Collection>>#anySatisfy:.

Cheers,
Adriaan.