default convention
Locked
12
12
 
|
Hi,
I would like to propose the convention of a default baseline in every configuration. This is particularly useful from a development point of view. We use this in all Moose projects with success. The scenario is like this: - default is a baseline (i.e., without explicit versions) - it represents the current development configuration - that means that we only work on the default - every time we want to create an explicit version, we copy default to a corresponding baseline and we create the version The benefit of this convention is that it provides a simple way to depend on a configuration for development without needing to update for every new version. For example, now we have ConfigurationOfGlamourSeaside and we want to depend on ConfigurationOfSeaside. In the current form, we can only depend on version "3.0.0-alpha5.15". However, for development purposes we would need access to the latest fixes which are not yet in a version. If there would be a default, we could just have our default depend on that one. What do you think? Cheers, Doru -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef." |
|
|
I like the idea but the word "default" does not mean to much to me on this context... I think we could use another word like "baseline" or "current" (I like baseline more...), don't you thinnk?
On Fri, Aug 6, 2010 at 5:11 PM, Tudor Girba <[hidden email]> wrote: Hi, -- Hernán Wilkinson
Agile Software Development, Teaching & Coaching Mobile: +54 - 11 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com |
|
|
In reply to this post by Tudor Girba
i know you like default :)
Now I would ban it (with an explicit configuration checker) from published version else we can end up in situation were we can only load the latest version. Stef On Aug 6, 2010, at 10:11 PM, Tudor Girba wrote: > Hi, > > I would like to propose the convention of a default baseline in every configuration. This is particularly useful from a development point of view. We use this in all Moose projects with success. > > The scenario is like this: > - default is a baseline (i.e., without explicit versions) > - it represents the current development configuration > - that means that we only work on the default > - every time we want to create an explicit version, we copy default to a corresponding baseline and we create the version > > The benefit of this convention is that it provides a simple way to depend on a configuration for development without needing to update for every new version. > > For example, now we have ConfigurationOfGlamourSeaside and we want to depend on ConfigurationOfSeaside. In the current form, we can only depend on version "3.0.0-alpha5.15". However, for development purposes we would need access to the latest fixes which are not yet in a version. If there would be a default, we could just have our default depend on that one. > > What do you think? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "No matter how many recipes we know, we still value a chef." > > > > > > |
|
|
In reply to this post by Hernan Wilkinson-3
default comes from "default configuration".
It is the default place you look at if nothing else is there, the default place you change, and the default version you want to load by default :). Cheers, Doru On 6 Aug 2010, at 23:25, Hernan Wilkinson wrote: > I like the idea but the word "default" does not mean to much to me > on this context... I think we could use another word like "baseline" > or "current" (I like baseline more...), don't you thinnk? > > On Fri, Aug 6, 2010 at 5:11 PM, Tudor Girba <[hidden email]> > wrote: > Hi, > > I would like to propose the convention of a default baseline in > every configuration. This is particularly useful from a development > point of view. We use this in all Moose projects with success. > > The scenario is like this: > - default is a baseline (i.e., without explicit versions) > - it represents the current development configuration > - that means that we only work on the default > - every time we want to create an explicit version, we copy default > to a corresponding baseline and we create the version > > The benefit of this convention is that it provides a simple way to > depend on a configuration for development without needing to update > for every new version. > > For example, now we have ConfigurationOfGlamourSeaside and we want > to depend on ConfigurationOfSeaside. In the current form, we can > only depend on version "3.0.0-alpha5.15". However, for development > purposes we would need access to the latest fixes which are not yet > in a version. If there would be a default, we could just have our > default depend on that one. > > What do you think? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "No matter how many recipes we know, we still value a chef." > > > > > > > > > > -- > Hernán Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 11 - 4470 - 7207 > email: [hidden email] > site: http://www.10Pines.com > -- www.tudorgirba.com "We cannot reach the flow of things unless we let go." |
|
|
In reply to this post by stephane ducasse-2
That is a good idea.
Cheers, Doru On 6 Aug 2010, at 23:36, stephane ducasse wrote: > i know you like default :) > Now I would ban it (with an explicit configuration checker) from > published version else we can end up in situation were we can only > load the latest version. > > Stef > On Aug 6, 2010, at 10:11 PM, Tudor Girba wrote: > >> Hi, >> >> I would like to propose the convention of a default baseline in >> every configuration. This is particularly useful from a development >> point of view. We use this in all Moose projects with success. >> >> The scenario is like this: >> - default is a baseline (i.e., without explicit versions) >> - it represents the current development configuration >> - that means that we only work on the default >> - every time we want to create an explicit version, we copy default >> to a corresponding baseline and we create the version >> >> The benefit of this convention is that it provides a simple way to >> depend on a configuration for development without needing to update >> for every new version. >> >> For example, now we have ConfigurationOfGlamourSeaside and we want >> to depend on ConfigurationOfSeaside. In the current form, we can >> only depend on version "3.0.0-alpha5.15". However, for development >> purposes we would need access to the latest fixes which are not yet >> in a version. If there would be a default, we could just have our >> default depend on that one. >> >> What do you think? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "No matter how many recipes we know, we still value a chef." >> >> >> >> >> >> > -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one." |
|
|
In reply to this post by Tudor Girba
I still don't like the "defulat" word for this :-)
On Fri, Aug 6, 2010 at 6:45 PM, Tudor Girba <[hidden email]> wrote: default comes from "default configuration". -- Hernán Wilkinson
Agile Software Development, Teaching & Coaching Mobile: +54 - 11 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com |
|
|
In reply to this post by Tudor Girba
Tudor,
I've been mulling this one over a bit and I think I'd like to suggest an alternate approach that is a little more general and can be applied in a few more use cases.... We are talking about project references and I've been bothered for awhile about the fact that when specifying a project reference, you have two choices (don't specify a version and you'll always get the #latestVersion) or specify an explicit version ... the #latestVersion is not bad, but it doesn't address the fact the #baselines should be treated differently. The explicit version isn't real useful when you are specifying a baseline .... too restrictive. Soo, I think that I'd like to extend the way that versions can be specified to include a "dynamic version spec". The idea is that you can specify a symbol as a _project_ version string: - '#latestVersion' is equivalent to the current no specification - '#lastVersion' allows for pulling in the #lastVersion of a project - '#lastBaseline' for pulling in the latest #baseline version These specifications can be used from within a baseline or a version spec, but only for project specs. Note that you can use a Symbol or a String for the spec (i.e., '#latestVersion' and #latestVersion should work). I also propose adding a corresponding #lastBaseline to MetacelloProject. If I'm not mistaken, this will satisfy your requirement for referencing other projects, since I believe that in your case the meaning of "current development configuration" is the latest version of everything... A convention isn't a bad idea, but we need an answer for configurations that don't follow the convention (or whose definition of default is not really what one wants)... I can imagine a situation where I would use #latestBaseline and #latestVersion for project specs in the latest baseline and latest version of a configuration, but when I find it necessary to create a new baseline or version, I would be inclined to replace the #latestBaseline and #latestVersion specs with the actual baseline and version, so that the spec would be locked down from that point forward ... Dale Tudor Girba wrote: > Hi, > > I would like to propose the convention of a default baseline in every > configuration. This is particularly useful from a development point of > view. We use this in all Moose projects with success. > > The scenario is like this: > - default is a baseline (i.e., without explicit versions) > - it represents the current development configuration > - that means that we only work on the default > - every time we want to create an explicit version, we copy default to > a corresponding baseline and we create the version > > The benefit of this convention is that it provides a simple way to > depend on a configuration for development without needing to update > for every new version. > > For example, now we have ConfigurationOfGlamourSeaside and we want to > depend on ConfigurationOfSeaside. In the current form, we can only > depend on version "3.0.0-alpha5.15". However, for development purposes > we would need access to the latest fixes which are not yet in a > version. If there would be a default, we could just have our default > depend on that one. > > What do you think? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "No matter how many recipes we know, we still value a chef." > > > > > > |
|
|
Hi Dale,
Sorry for the late reply. I somehow lost track of this thread :(. The problem is that baseline is still a naming convention. So, for example, if I have #default as a baseline, and #aProject-baseline.xxx as the baselines, #default will always be the lastBaseline. Perhaps we could introduce an explicit pragma to distinguish between versions, baselines and "current"? Cheers, Doru On 9 Aug 2010, at 21:15, Dale Henrichs wrote: > Tudor, > > I've been mulling this one over a bit and I think I'd like to > suggest an alternate approach that is a little more general and can > be applied in a few more use cases.... > > We are talking about project references and I've been bothered for > awhile about the fact that when specifying a project reference, you > have two choices (don't specify a version and you'll always get the > #latestVersion) or specify an explicit version ... the > #latestVersion is not bad, but it doesn't address the fact the > #baselines should be treated differently. The explicit version isn't > real useful when you are specifying a baseline .... too restrictive. > > Soo, I think that I'd like to extend the way that versions can be > specified to include a "dynamic version spec". > > The idea is that you can specify a symbol as a _project_ version > string: > > - '#latestVersion' is equivalent to the current no specification > - '#lastVersion' allows for pulling in the #lastVersion of a project > - '#lastBaseline' for pulling in the latest #baseline version > > These specifications can be used from within a baseline or a version > spec, but only for project specs. Note that you can use a Symbol or > a String for the spec (i.e., '#latestVersion' and #latestVersion > should work). > > I also propose adding a corresponding #lastBaseline to > MetacelloProject. > > If I'm not mistaken, this will satisfy your requirement for > referencing other projects, since I believe that in your case the > meaning of "current development configuration" is the latest version > of everything... > > A convention isn't a bad idea, but we need an answer for > configurations that don't follow the convention (or whose definition > of default is not really what one wants)... > > I can imagine a situation where I would use #latestBaseline and > #latestVersion for project specs in the latest baseline and latest > version of a configuration, but when I find it necessary to create a > new baseline or version, I would be inclined to replace the > #latestBaseline and #latestVersion specs with the actual baseline > and version, so that the spec would be locked down from that point > forward ... > > Dale > > Tudor Girba wrote: >> Hi, >> I would like to propose the convention of a default baseline in >> every configuration. This is particularly useful from a >> development point of view. We use this in all Moose projects with >> success. >> The scenario is like this: >> - default is a baseline (i.e., without explicit versions) >> - it represents the current development configuration >> - that means that we only work on the default >> - every time we want to create an explicit version, we copy default >> to a corresponding baseline and we create the version >> The benefit of this convention is that it provides a simple way to >> depend on a configuration for development without needing to >> update for every new version. >> For example, now we have ConfigurationOfGlamourSeaside and we want >> to depend on ConfigurationOfSeaside. In the current form, we can >> only depend on version "3.0.0-alpha5.15". However, for development >> purposes we would need access to the latest fixes which are not >> yet in a version. If there would be a default, we could just have >> our default depend on that one. >> What do you think? >> Cheers, >> Doru >> -- >> www.tudorgirba.com >> "No matter how many recipes we know, we still value a chef." > -- www.tudorgirba.com "Live like you mean it." |
|
|
Doru,
Now I'm sorry that I lost the thread, too... Let me think on your suggestion a bit ... I agree that my suggestion doesn't solve your problem and I like the idea of an explicit pragma better than naming ... I think ... just a thought ... would #current as a blessing: fill the bill? Dale Tudor Girba wrote: > Hi Dale, > > Sorry for the late reply. I somehow lost track of this thread :(. > > The problem is that baseline is still a naming convention. So, for > example, if I have #default as a baseline, and #aProject-baseline.xxx > as the baselines, #default will always be the lastBaseline. > > Perhaps we could introduce an explicit pragma to distinguish between > versions, baselines and "current"? > > Cheers, > Doru > > > On 9 Aug 2010, at 21:15, Dale Henrichs wrote: > >> Tudor, >> >> I've been mulling this one over a bit and I think I'd like to >> suggest an alternate approach that is a little more general and can >> be applied in a few more use cases.... >> >> We are talking about project references and I've been bothered for >> awhile about the fact that when specifying a project reference, you >> have two choices (don't specify a version and you'll always get the >> #latestVersion) or specify an explicit version ... the >> #latestVersion is not bad, but it doesn't address the fact the >> #baselines should be treated differently. The explicit version isn't >> real useful when you are specifying a baseline .... too restrictive. >> >> Soo, I think that I'd like to extend the way that versions can be >> specified to include a "dynamic version spec". >> >> The idea is that you can specify a symbol as a _project_ version >> string: >> >> - '#latestVersion' is equivalent to the current no specification >> - '#lastVersion' allows for pulling in the #lastVersion of a project >> - '#lastBaseline' for pulling in the latest #baseline version >> >> These specifications can be used from within a baseline or a version >> spec, but only for project specs. Note that you can use a Symbol or >> a String for the spec (i.e., '#latestVersion' and #latestVersion >> should work). >> >> I also propose adding a corresponding #lastBaseline to >> MetacelloProject. >> >> If I'm not mistaken, this will satisfy your requirement for >> referencing other projects, since I believe that in your case the >> meaning of "current development configuration" is the latest version >> of everything... >> >> A convention isn't a bad idea, but we need an answer for >> configurations that don't follow the convention (or whose definition >> of default is not really what one wants)... >> >> I can imagine a situation where I would use #latestBaseline and >> #latestVersion for project specs in the latest baseline and latest >> version of a configuration, but when I find it necessary to create a >> new baseline or version, I would be inclined to replace the >> #latestBaseline and #latestVersion specs with the actual baseline >> and version, so that the spec would be locked down from that point >> forward ... >> >> Dale >> >> Tudor Girba wrote: >>> Hi, >>> I would like to propose the convention of a default baseline in >>> every configuration. This is particularly useful from a >>> development point of view. We use this in all Moose projects with >>> success. >>> The scenario is like this: >>> - default is a baseline (i.e., without explicit versions) >>> - it represents the current development configuration >>> - that means that we only work on the default >>> - every time we want to create an explicit version, we copy default >>> to a corresponding baseline and we create the version >>> The benefit of this convention is that it provides a simple way to >>> depend on a configuration for development without needing to >>> update for every new version. >>> For example, now we have ConfigurationOfGlamourSeaside and we want >>> to depend on ConfigurationOfSeaside. In the current form, we can >>> only depend on version "3.0.0-alpha5.15". However, for development >>> purposes we would need access to the latest fixes which are not >>> yet in a version. If there would be a default, we could just have >>> our default depend on that one. >>> What do you think? >>> Cheers, >>> Doru >>> -- >>> www.tudorgirba.com >>> "No matter how many recipes we know, we still value a chef." > > -- > www.tudorgirba.com > > "Live like you mean it." > |
|
|
Hi,
> Now I'm sorry that I lost the thread, too... > > Let me think on your suggestion a bit ... I agree that my suggestion > doesn't solve your problem and I like the idea of an explicit pragma > better than naming ... I think ... > > just a thought ... would #current as a blessing: fill the bill? I think a blessing does not solve the problem. The same blessing can appear in many versions. I want to easily be able to refer to a unique baseline. Btw, the other benefit of a "current" baseline is that I do not have to think what to modify. I always modify the current one, instead of needing to go in the list to pick the latest one. This simplifies the workflow and makes it easy to communicate to others what they should do (just like the ConfigurationOf made it pretty easy for people to identify starting points). Cheers, Doru > Dale > > Tudor Girba wrote: >> Hi Dale, >> Sorry for the late reply. I somehow lost track of this thread :(. >> The problem is that baseline is still a naming convention. So, for >> example, if I have #default as a baseline, and #aProject- >> baseline.xxx as the baselines, #default will always be the >> lastBaseline. >> Perhaps we could introduce an explicit pragma to distinguish >> between versions, baselines and "current"? >> Cheers, >> Doru >> On 9 Aug 2010, at 21:15, Dale Henrichs wrote: >>> Tudor, >>> >>> I've been mulling this one over a bit and I think I'd like to >>> suggest an alternate approach that is a little more general and >>> can be applied in a few more use cases.... >>> >>> We are talking about project references and I've been bothered >>> for awhile about the fact that when specifying a project >>> reference, you have two choices (don't specify a version and >>> you'll always get the #latestVersion) or specify an explicit >>> version ... the #latestVersion is not bad, but it doesn't address >>> the fact the #baselines should be treated differently. The >>> explicit version isn't real useful when you are specifying a >>> baseline .... too restrictive. >>> >>> Soo, I think that I'd like to extend the way that versions can be >>> specified to include a "dynamic version spec". >>> >>> The idea is that you can specify a symbol as a _project_ version >>> string: >>> >>> - '#latestVersion' is equivalent to the current no specification >>> - '#lastVersion' allows for pulling in the #lastVersion of a project >>> - '#lastBaseline' for pulling in the latest #baseline version >>> >>> These specifications can be used from within a baseline or a >>> version spec, but only for project specs. Note that you can use a >>> Symbol or a String for the spec (i.e., '#latestVersion' and >>> #latestVersion should work). >>> >>> I also propose adding a corresponding #lastBaseline to >>> MetacelloProject. >>> >>> If I'm not mistaken, this will satisfy your requirement for >>> referencing other projects, since I believe that in your case the >>> meaning of "current development configuration" is the latest >>> version of everything... >>> >>> A convention isn't a bad idea, but we need an answer for >>> configurations that don't follow the convention (or whose >>> definition of default is not really what one wants)... >>> >>> I can imagine a situation where I would use #latestBaseline and >>> #latestVersion for project specs in the latest baseline and >>> latest version of a configuration, but when I find it necessary >>> to create a new baseline or version, I would be inclined to >>> replace the #latestBaseline and #latestVersion specs with the >>> actual baseline and version, so that the spec would be locked >>> down from that point forward ... >>> >>> Dale >>> >>> Tudor Girba wrote: >>>> Hi, >>>> I would like to propose the convention of a default baseline in >>>> every configuration. This is particularly useful from a >>>> development point of view. We use this in all Moose projects >>>> with success. >>>> The scenario is like this: >>>> - default is a baseline (i.e., without explicit versions) >>>> - it represents the current development configuration >>>> - that means that we only work on the default >>>> - every time we want to create an explicit version, we copy >>>> default to a corresponding baseline and we create the version >>>> The benefit of this convention is that it provides a simple way >>>> to depend on a configuration for development without needing >>>> to update for every new version. >>>> For example, now we have ConfigurationOfGlamourSeaside and we >>>> want to depend on ConfigurationOfSeaside. In the current form, >>>> we can only depend on version "3.0.0-alpha5.15". However, for >>>> development purposes we would need access to the latest fixes >>>> which are not yet in a version. If there would be a default, we >>>> could just have our default depend on that one. >>>> What do you think? >>>> Cheers, >>>> Doru >>>> -- >>>> www.tudorgirba.com >>>> "No matter how many recipes we know, we still value a chef." >> -- >> www.tudorgirba.com >> "Live like you mean it." -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them." |
|
|
In reply to this post by Tudor Girba
Doru,
I was wondering if you have been following the symbolic version discussion? In my mind I have imagined that the symbolic versions will address your desire to have a convention for what has come to be known as the #bleedingEdgeVersion. Earlier today, Mariano made a good argument against having a default behavior for #stableVersion, but I think that there is a case for having default behaviors defined for #developmentVersin and #bleedingEdge, so that we would move from a convention into being able to depend upon there being a definition for #bleedingEdge... If we do have a default behavior for #bleedingEdge, it should be implemented as a standard method in the config which is consistent with the lookup/message send pattern I am proposing ... Regardless, I am interested to hear your thoughts on the directions we are going with symbolic versions as it relates to your desire for a 'default convention'. Dale Tudor Girba wrote: > Hi, > > I would like to propose the convention of a default baseline in every > configuration. This is particularly useful from a development point of > view. We use this in all Moose projects with success. > > The scenario is like this: > - default is a baseline (i.e., without explicit versions) > - it represents the current development configuration > - that means that we only work on the default > - every time we want to create an explicit version, we copy default to > a corresponding baseline and we create the version > > The benefit of this convention is that it provides a simple way to > depend on a configuration for development without needing to update > for every new version. > > For example, now we have ConfigurationOfGlamourSeaside and we want to > depend on ConfigurationOfSeaside. In the current form, we can only > depend on version "3.0.0-alpha5.15". However, for development purposes > we would need access to the latest fixes which are not yet in a > version. If there would be a default, we could just have our default > depend on that one. > > What do you think? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "No matter how many recipes we know, we still value a chef." > > > > > > |
|
|
On Wed, Sep 29, 2010 at 7:31 PM, Dale Henrichs <[hidden email]> wrote: Doru, :) My ideal would be: no default in Metacello, but Metacello be flexible enough so that a Configuration can define a default if wanted :) like Moose here This is why maybe having the methods is worth it since they can be overridden. If we do have a default behavior for #bleedingEdge, it should be implemented as a standard method in the config which is consistent with the lookup/message send pattern I am proposing ... |
|
|
mariano the problem with methods and behavior overwritting is that you will not be able to build analysis.
This the difference between a declarative model and an imperative executable one. Stef On Sep 29, 2010, at 7:34 PM, Mariano Martinez Peck wrote: > > > On Wed, Sep 29, 2010 at 7:31 PM, Dale Henrichs <[hidden email]> wrote: > Doru, > > I was wondering if you have been following the symbolic version discussion? > > In my mind I have imagined that the symbolic versions will address your desire to have a convention for what has come to be known as the #bleedingEdgeVersion. > > Earlier today, Mariano made a good argument against having a default behavior for #stableVersion, but I think that there is a case for having default behaviors defined for #developmentVersin and #bleedingEdge, so that we would move from a convention into being able to depend upon there being a definition for #bleedingEdge... > > > :) My ideal would be: no default in Metacello, but Metacello be flexible enough so that a Configuration can define a default if wanted :) like Moose here > This is why maybe having the methods is worth it since they can be overridden. > > If we do have a default behavior for #bleedingEdge, it should be implemented as a standard method in the config which is consistent with the lookup/message send pattern I am proposing ... > > Regardless, I am interested to hear your thoughts on the directions we are going with symbolic versions as it relates to your desire for a 'default convention'. > > Dale > > > Tudor Girba wrote: > Hi, > > I would like to propose the convention of a default baseline in every configuration. This is particularly useful from a development point of view. We use this in all Moose projects with success. > > The scenario is like this: > - default is a baseline (i.e., without explicit versions) > - it represents the current development configuration > - that means that we only work on the default > - every time we want to create an explicit version, we copy default to a corresponding baseline and we create the version > > The benefit of this convention is that it provides a simple way to depend on a configuration for development without needing to update for every new version. > > For example, now we have ConfigurationOfGlamourSeaside and we want to depend on ConfigurationOfSeaside. In the current form, we can only depend on version "3.0.0-alpha5.15". However, for development purposes we would need access to the latest fixes which are not yet in a version. If there would be a default, we could just have our default depend on that one. > > What do you think? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "No matter how many recipes we know, we still value a chef." > > > > > > > > |
|
|
In reply to this post by Mariano Martinez Peck
Mariano Martinez Peck wrote:
> > > On Wed, Sep 29, 2010 at 7:31 PM, Dale Henrichs <[hidden email] > <mailto:[hidden email]>> wrote: > > Doru, > > I was wondering if you have been following the symbolic version > discussion? > > In my mind I have imagined that the symbolic versions will address > your desire to have a convention for what has come to be known as > the #bleedingEdgeVersion. > > Earlier today, Mariano made a good argument against having a default > behavior for #stableVersion, but I think that there is a case for > having default behaviors defined for #developmentVersin and > #bleedingEdge, so that we would move from a convention into being > able to depend upon there being a definition for #bleedingEdge... > > > :) My ideal would be: no default in Metacello, but Metacello be > flexible enough so that a Configuration can define a default if wanted > :) like Moose here > This is why maybe having the methods is worth it since they can be > overridden. I understand, but I think that #bleedingEdge is a special case...The reason that Doru requested this in the first place is that it is difficult for a user of a project to use the #bleedingEdge for _other_ projects. The "causing confusion" argument doesn't hold for #bleedingEdge ... the whole intent of bleedingEdge is to load the absolute latest version of every package in every project so unexpected behavior is the rule rather than the exception. Having a default bleedingEdge would mean that a project maintainer doesn't have to think about what the bleedingEdge would be, since the default for bleedingEdge is adequate 90% of the time. Finally, I would implement the default behavior by including a #bleedingEdge method in the standard template making it a defacto default and users who don't want to support bleedingEdge behaviour can remove the #bleedingEdge method from their configuration. So I think we just might be in agreement here:) Dale |
|
|
In reply to this post by stephane ducasse-2
stephane ducasse wrote:
> mariano the problem with methods and behavior overwritting is that you will not be able to build analysis. > This the difference between a declarative model and an imperative executable one. > > Stef Stef, We _are_ walking a fine line in using methods as a backup to doing a direct lookup, however, the message could be sent during spec construction (unlike the doit methods which are evaluated at load time). The project spec that is produced would be declarative, because all of the symbolic versions (whether or not explicitly declared in the config or defined via message send) would be resolved to a specific version ... Can we have our cake and eat it too? Dale |
|
|
On Sep 29, 2010, at 8:43 PM, Dale Henrichs wrote: > stephane ducasse wrote: >> mariano the problem with methods and behavior overwritting is that you will not be able to build analysis. >> This the difference between a declarative model and an imperative executable one. Stef > > Stef, > > We _are_ walking a fine line in using methods as a backup to doing a direct lookup, however, the message could be sent during spec construction (unlike the doit methods which are evaluated at load time). > > The project spec that is produced would be declarative, because all of the symbolic versions (whether or not explicitly declared in the config or defined via message send) would be resolved to a specific version ... > > Can we have our cake and eat it too? that I'm not sure or it means that the specification of the hooks is clear enough so that overriding returns elements that are conceptually the same as the default ones. In such a case we can build tools that do not care how the results are computed but just need the results. In such a case it can work else we will have black all inside a declarative model. Like the postscript in packages. there is no way to build a real package merging tools or we get do post1 and post2 not knowing what there are doing. So we are in sync > > Dale |
|
|
In reply to this post by Dale Henrichs
On Wed, Sep 29, 2010 at 8:24 PM, Dale Henrichs <[hidden email]> wrote: Mariano Martinez Peck wrote: Excellent. I agree. Dale |
|
|
In reply to this post by stephane ducasse-2
On Wed, Sep 29, 2010 at 8:24 PM, stephane ducasse <[hidden email]> wrote: mariano the problem with methods and behavior overwritting is that you will not be able to build analysis. I didn't understand. Don't worry, on Friday you can explain me :)
|
|
|
In reply to this post by stephane ducasse-2
> mariano the problem with methods and behavior overwritting is that you will not be able to build analysis.
> This the difference between a declarative model and an imperative executable one. +1 Alexandre > > On Sep 29, 2010, at 7:34 PM, Mariano Martinez Peck wrote: > >> >> >> On Wed, Sep 29, 2010 at 7:31 PM, Dale Henrichs <[hidden email]> wrote: >> Doru, >> >> I was wondering if you have been following the symbolic version discussion? >> >> In my mind I have imagined that the symbolic versions will address your desire to have a convention for what has come to be known as the #bleedingEdgeVersion. >> >> Earlier today, Mariano made a good argument against having a default behavior for #stableVersion, but I think that there is a case for having default behaviors defined for #developmentVersin and #bleedingEdge, so that we would move from a convention into being able to depend upon there being a definition for #bleedingEdge... >> >> >> :) My ideal would be: no default in Metacello, but Metacello be flexible enough so that a Configuration can define a default if wanted :) like Moose here >> This is why maybe having the methods is worth it since they can be overridden. >> >> If we do have a default behavior for #bleedingEdge, it should be implemented as a standard method in the config which is consistent with the lookup/message send pattern I am proposing ... >> >> Regardless, I am interested to hear your thoughts on the directions we are going with symbolic versions as it relates to your desire for a 'default convention'. >> >> Dale >> >> >> Tudor Girba wrote: >> Hi, >> >> I would like to propose the convention of a default baseline in every configuration. This is particularly useful from a development point of view. We use this in all Moose projects with success. >> >> The scenario is like this: >> - default is a baseline (i.e., without explicit versions) >> - it represents the current development configuration >> - that means that we only work on the default >> - every time we want to create an explicit version, we copy default to a corresponding baseline and we create the version >> >> The benefit of this convention is that it provides a simple way to depend on a configuration for development without needing to update for every new version. >> >> For example, now we have ConfigurationOfGlamourSeaside and we want to depend on ConfigurationOfSeaside. In the current form, we can only depend on version "3.0.0-alpha5.15". However, for development purposes we would need access to the latest fixes which are not yet in a version. If there would be a default, we could just have our default depend on that one. >> >> What do you think? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "No matter how many recipes we know, we still value a chef." >> >> >> >> >> >> >> >> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
On Thu, Sep 30, 2010 at 4:19 PM, Alexandre Bergel <[hidden email]> wrote:
I still don't understand. Can someone explain me? thanks mariano
|
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |