Hi Dale. I was thinking the following. I have a particular scenario when using Metacello (what I will show in Smalltalks) where from one Conf* I have a lot of definitions of project references or packages. Example:
spec for: #pharo do: [ spec blessing: #baseline. "spec repository: 'http://www.squeaksource.com/Fuel'. " spec project: 'XXX' with: [ .... ] spec project: 'YYY' with: [ .... ] spec project: 'ZZZ' with: [ .... ] spec project: 'TTT' with: [ .... ] Now....I would like to group them, because in fact, there are groups of related configs. Creating a separate config to group them is too much, overkiling. So far I am separating them using comments: " THE FOLLOWING GROUPS ARE .... " spec project: 'ZZZ' with: [ .... ] spec project: 'TTT' with: [ .... ] Now I was wondering what do you think about the following. For example spec for: #pharo do: [ spec blessing: #baseline. "spec repository: 'http://www.squeaksource.com/Fuel'. " self groupOfProjectAAAWith: spec. self groupOfProjectBBBWith: spec. ... ] And of course: >> groupOfProjectAAAWith: spec spec project: 'ZZZ' with: [ .... ] spec project: 'TTT' with: [ .... ] What do you think? I mean....it works. is it too hacky? thanks! -- Mariano http://marianopeck.wordpress.com |
I think that it is interesting and it obviously is functional ... the thing that I think I dislike about breaking up the version methods (via includes or other method calls) is that it is too easy to modify a released version when there are shared specifications and that is an absolute no no ... When the specification is spread out over several methods it is not easy to get a good picture of what's actually defined in the spec and making changes that are correct can be difficult ...
IN the end, if there is a technique that makes it easier for you to manage the config then you should use it ... just be sure that you isolate things enough and avoid making it too easy to modify existing configs ... Dale ----- Original Message ----- | From: "Mariano Martinez Peck" <[hidden email]> | To: [hidden email] | Sent: Thursday, October 20, 2011 12:14:11 PM | Subject: [Metacello] Factoring out pieces of Conf* | | Hi Dale. I was thinking the following. I have a particular scenario | when using Metacello (what I will show in Smalltalks) where from one | Conf* I have a lot of definitions of project references or packages. | Example: | | | | spec for: #pharo do: [ | spec blessing: #baseline. | "spec repository: ' http://www.squeaksource.com/Fuel '. " | | | spec | project: 'XXX' with: [ | .... | ] | | | spec | project: 'YYY' with: [ | .... | ] | | | spec | project: 'ZZZ' with: [ | .... | ] | | | spec | project: 'TTT' with: [ | .... | ] | | Now....I would like to group them, because in fact, there are groups | of related configs. Creating a separate config to group them is too | much, overkiling. So far I am separating them using comments: | | | " | THE FOLLOWING GROUPS ARE .... | " | spec | project: 'ZZZ' with: [ | .... | ] | | | spec | project: 'TTT' with: [ | .... | ] | | | Now I was wondering what do you think about the following. For | example | | spec for: #pharo do: [ | spec blessing: #baseline. | "spec repository: ' http://www.squeaksource.com/Fuel '. " | | | self groupOfProjectAAAWith: spec. | self groupOfProjectBBBWith: spec. | ... | | ] | | | And of course: | | >> groupOfProjectAAAWith: spec | | spec | project: 'ZZZ' with: [ | .... | ] | | | spec | project: 'TTT' with: [ | .... | ] | | | What do you think? I mean....it works. is it too hacky? | | thanks! | | | -- | Mariano | http://marianopeck.wordpress.com | | |
+1
Alexandre On 20 Oct 2011, at 16:32, Dale Henrichs wrote: > I think that it is interesting and it obviously is functional ... the thing that I think I dislike about breaking up the version methods (via includes or other method calls) is that it is too easy to modify a released version when there are shared specifications and that is an absolute no no ... When the specification is spread out over several methods it is not easy to get a good picture of what's actually defined in the spec and making changes that are correct can be difficult ... > > IN the end, if there is a technique that makes it easier for you to manage the config then you should use it ... just be sure that you isolate things enough and avoid making it too easy to modify existing configs ... > > Dale > > ----- Original Message ----- > | From: "Mariano Martinez Peck" <[hidden email]> > | To: [hidden email] > | Sent: Thursday, October 20, 2011 12:14:11 PM > | Subject: [Metacello] Factoring out pieces of Conf* > | > | Hi Dale. I was thinking the following. I have a particular scenario > | when using Metacello (what I will show in Smalltalks) where from one > | Conf* I have a lot of definitions of project references or packages. > | Example: > | > | > | > | spec for: #pharo do: [ > | spec blessing: #baseline. > | "spec repository: ' http://www.squeaksource.com/Fuel '. " > | > | > | spec > | project: 'XXX' with: [ > | .... > | ] > | > | > | spec > | project: 'YYY' with: [ > | .... > | ] > | > | > | spec > | project: 'ZZZ' with: [ > | .... > | ] > | > | > | spec > | project: 'TTT' with: [ > | .... > | ] > | > | Now....I would like to group them, because in fact, there are groups > | of related configs. Creating a separate config to group them is too > | much, overkiling. So far I am separating them using comments: > | > | > | " > | THE FOLLOWING GROUPS ARE .... > | " > | spec > | project: 'ZZZ' with: [ > | .... > | ] > | > | > | spec > | project: 'TTT' with: [ > | .... > | ] > | > | > | Now I was wondering what do you think about the following. For > | example > | > | spec for: #pharo do: [ > | spec blessing: #baseline. > | "spec repository: ' http://www.squeaksource.com/Fuel '. " > | > | > | self groupOfProjectAAAWith: spec. > | self groupOfProjectBBBWith: spec. > | ... > | > | ] > | > | > | And of course: > | > | >> groupOfProjectAAAWith: spec > | > | spec > | project: 'ZZZ' with: [ > | .... > | ] > | > | > | spec > | project: 'TTT' with: [ > | .... > | ] > | > | > | What do you think? I mean....it works. is it too hacky? > | > | thanks! > | > | > | -- > | Mariano > | http://marianopeck.wordpress.com > | > | -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
In reply to this post by Dale Henrichs
On Thu, Oct 20, 2011 at 9:32 PM, Dale Henrichs <[hidden email]> wrote: I think that it is interesting and it obviously is functional ... the thing that I think I dislike about breaking up the version methods (via includes or other method calls) is that it is too easy to modify a released version when there are shared specifications and that is an absolute no no ... When the specification is spread out over several methods it is not easy to get a good picture of what's actually defined in the spec and making changes that are correct can be difficult ... Ahh good point :)
Exactly! In this particular scenario, I could use it because I have no versions at all. I am not sure if I will end up using it, but I found cool that in fact I was ABLE to do it without problems. Cheers
-- Mariano http://marianopeck.wordpress.com |
Hehe, lately do things like:
#( 'subpackage1' 'subpackage1' 'subpackage1') do: [ :subpackage | spec package: 'Something-' , subpackage ]. It's just code, so I have fun :D On Thu, Oct 20, 2011 at 5:44 PM, Mariano Martinez Peck <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |