Cross-fork Metacello configurations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Cross-fork Metacello configurations

Sean P. DeNigris
Administrator
I created a Squeak/Pharo SSpec, which puts the fork-specific world menu code into a Platform package.

As I work on the config, I have come up against Pharo using Object as a subclass, but the Squeak Inbox requiring (because of the browser tool) MetacelloConfiguration.

What would be the best/easiest way to deal with this?

If the configs have to be forked, then Metacello really loses value (i.e. #squeak and #pharo).  And, I do a lot of work in both forks, so it would be a shame to pick one to upload to and not share work that has already been done with half the users.

Thanks.
Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Cross-fork Metacello configurations

Bert Freudenberg
On 21.05.2010, at 18:14, Sean P. DeNigris wrote:

>
>
> I created a Squeak/Pharo SSpec, which puts the fork-specific world menu code
> into a Platform package.
>
> As I work on the config, I have come up against Pharo using Object as a
> subclass, but the Squeak Inbox requiring (because of the browser tool)
> MetacelloConfiguration.
>
> What would be the best/easiest way to deal with this?

If the systems require different configurations, then there should be different configurations.

> If the configs have to be forked, then Metacello really loses value (i.e.
> #squeak and #pharo).  And, I do a lot of work in both forks, so it would be
> a shame to pick one to upload to and not share work that has already been
> done with half the users.
>
> Thanks.
> Sean

Perhaps it indeed would be a good idea to not use ConfigurationOf* class names, as previously suggested. Using the same name implies re-usability, but these configurations are system specific. They are also quite small, re-using configurations is not that important. What *is* more important is that the configuration has actually been tested in Squeak, and not just been copied over from other places.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: Cross-fork Metacello configurations

Sean P. DeNigris
Administrator
Bert Freudenberg wrote
If the systems require different configurations, then there should be different configurations.
Absolutely, and Metacello already handles the difference.  Handling it by creating two separate Classes is solving a problem that doesn't exist, while creating a problem for developers - who now have to do extra work for no discernible reason.

Bert Freudenberg wrote
re-using configurations is not that important
Maybe not for code reuse, but logistically, it's much harder.  I'm going through SqS and SqMap making old interesting projects loadable.  A little more effort * 100 projects is significant.

Bert Freudenberg wrote
What *is* more important is that the configuration has actually been tested in Squeak, and not just been copied over from other places.
Yes, but that is irrelevant here.  If someone adds the config to the inbox, that presumably means they have tested it in Squeak.  And, there would be nothing to prevent someone from creating a new config from scratch that didn't work; maybe more likely not to work because a perfectly good config has to be split apart.  Anyway, I thought that's why we're going to do automatic testing.

In summary, if we can make life easier, why not?  For example, couldn't ConfigBrowser select classes that start with ConfigurationOf instead of MetacelloConfigruation subclasses?

Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Cross-fork Metacello configurations

Hannes Hirzel
On 5/21/10, Sean P. DeNigris <[hidden email]> wrote:
....
> In summary, if we can make life easier, why not?  For example, couldn't
> ConfigBrowser select classes that start with ConfigurationOf instead of
> MetacelloConfigruation subclasses?
>

Worthwhile considering....

--Hannes

Reply | Threaded
Open this post in threaded view
|

Re: Cross-fork Metacello configurations

Andreas.Raab
In reply to this post by Sean P. DeNigris
On 5/21/2010 9:14 AM, Sean P. DeNigris wrote:
> What would be the best/easiest way to deal with this?
>
> If the configs have to be forked, then Metacello really loses value (i.e.
> #squeak and #pharo).  And, I do a lot of work in both forks, so it would be
> a shame to pick one to upload to and not share work that has already been
> done with half the users.

How about you try using a proxy configuration for that? We've talked
about this earlier: If you want to keep a single configuration
externally, make a proxy config that simply loads the external config.
It would be good to have an example for that.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Cross-fork Metacello configurations

Andreas.Raab
In reply to this post by Bert Freudenberg
On 5/21/2010 10:22 AM, Bert Freudenberg wrote:
>> If the configs have to be forked, then Metacello really loses value (i.e.
>> #squeak and #pharo).  And, I do a lot of work in both forks, so it would be
>> a shame to pick one to upload to and not share work that has already been
>> done with half the users.
>
> Perhaps it indeed would be a good idea to not use ConfigurationOf* class names, as previously suggested. Using the same name implies re-usability, but these configurations are system specific. They are also quite small, re-using configurations is not that important. What *is* more important is that the configuration has actually been tested in Squeak, and not just been copied over from other places.

I've been starting to wonder about this. Here's a question: How do we
expect this to be used? I suspect that the most use for "polymorphic
configs" will be certain standard libraries, for example the FFI or
HelpSystem. Having different names for those seems problematic, because
it creates more work for whoever wants to use that config - the
polymorphic name, i.e., ConfigurationOfFFI makes sure you get the right
thing regardless on platform you're running on.

I think we need some actual examples here, and how the results would look.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Cross-fork Metacello configurations

Sean P. DeNigris
Administrator
In reply to this post by Andreas.Raab
> How about you try using a proxy configuration for that? We've talked
> about this earlier: If you want to keep a single configuration
> externally, make a proxy config that simply loads the external config.
> It would be good to have an example for that.

Oh yeah.  Thanks for the reminder.  Still sorting everything out in my  
head. I am away from the computer for the weekend, will try when I get  
back.  One thing that's come up: it seems like I'll have to call the  
proxy something other than ConfigurationOfXxx or the name will clash  
when I load the pre-existing external one.  Any thoughts?

Sent from my iPhone
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Cross-fork Metacello configurations

Hannes Hirzel
On 5/22/10, Sean P. DeNigris <[hidden email]> wrote:

>
>> How about you try using a proxy configuration for that? We've talked
>> about this earlier: If you want to keep a single configuration
>> externally, make a proxy config that simply loads the external config.
>> It would be good to have an example for that.
>
> Oh yeah.  Thanks for the reminder.  Still sorting everything out in my
> head. I am away from the computer for the weekend, will try when I get
> back.  One thing that's come up: it seems like I'll have to call the
> proxy something other than ConfigurationOfXxx or the name will clash
> when I load the pre-existing external one.

Yes, the proxy has to be named differently.
If I have ConfigurationOfXxx it should actually be the same item
whether it is at http://www.squeaksource.com/MetacelloRepository.html
or it is in the image.

If it has been changed it should be named differently.

--Hannes

bpi
Reply | Threaded
Open this post in threaded view
|

Re: Cross-fork Metacello configurations

bpi
In reply to this post by Sean P. DeNigris
Dear Squeakers,

I agree with Sean that the necessity to copy a configuration class from a cross-fork package ConfigurationOf... to the proposed Configuration package for Squeak makes life much more complicated and more work for those good fellows who care to create portable packages. IMHO that is a bad things for all forks. The ability to support cross-fork development is one of the greatest assets of Metacello. I see no reason not to use it.

The good news is that - as Sean already wrote - all the good things of Andreas proposal could work equally well even if we reused the cross-fork ConfigurationOf... packages. The fact that some core developer copies such a package to the trunk could mean it was tested with Squeak. The only difference would be having more packages in the Monticello Browser. (They could be hidden from there.)

IIUC one thing misses from Metacello right now to use it in the way Andreas envisions: A categorization for an installer UI like Andreas' ConfigBrowser. I am sure Dale could be convinced to add that to the metadata/API if cross-development configurations could continue to be supported.

Did I miss something?

Just my 2 cents.

Cheers,
Bernhard

Am 21.05.2010 um 20:14 schrieb Sean P. DeNigris:

>
>
> Bert Freudenberg wrote:
>>
>> If the systems require different configurations, then there should be
>> different configurations.
>>
> Absolutely, and Metacello already handles the difference.  Handling it by
> creating two separate Classes is solving a problem that doesn't exist, while
> creating a problem for developers - who now have to do extra work for no
> discernible reason.
>
>
> Bert Freudenberg wrote:
>>
>> re-using configurations is not that important
>>
> Maybe not for code reuse, but logistically, it's much harder.  I'm going
> through SqS and SqMap making old interesting projects loadable.  A little
> more effort * 100 projects is significant.
>
>
> Bert Freudenberg wrote:
>>
>> What *is* more important is that the configuration has actually been
>> tested in Squeak, and not just been copied over from other places.
>>
>
> Yes, but that is irrelevant here.  If someone adds the config to the inbox,
> that presumably means they have tested it in Squeak.  And, there would be
> nothing to prevent someone from creating a new config from scratch that
> didn't work; maybe more likely not to work because a perfectly good config
> has to be split apart.  Anyway, I thought that's why we're going to do
> automatic testing.
>
> In summary, if we can make life easier, why not?  For example, couldn't
> ConfigBrowser select classes that start with ConfigurationOf instead of
> MetacelloConfigruation subclasses?
>
> Sean
> --
> View this message in context: http://forum.world.st/Cross-fork-Metacello-configurations-tp2226390p2226525.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>