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 |
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 - |
Administrator
|
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. 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. 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 |
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 |
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 |
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 |
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 |
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 |
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. > |
Free forum by Nabble | Edit this page |