default convention
Locked
12
12
 
|
look at the postscript in a cs.
There are not methodDefinition, classDefinition... With methodDefinition, class defintion we could imagine that we can sort them compare them eliminate them. They represent our vocabulary Now post script are plain smalltalk expressions so everything can happen. Then suddenly you have black holes in your analysis possibilities stef On Oct 5, 2010, at 6:54 PM, Mariano Martinez Peck wrote: > > > On Thu, Sep 30, 2010 at 4:19 PM, Alexandre Bergel <[hidden email]> 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. > > > I still don't understand. Can someone explain me? > thanks > > mariano > > +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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > |
|
|
In reply to this post by Tudor Girba
On 08/06/2010 01: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? Doru, I am still wondering if you and I are on the same page with symbolicVersions and the 'default' convention. With symbolicVersions we have the notion of a #bleedingEdgeVersion by default defined as the latest #baseline version: bleedingEdgeVersion <symbolicVersion: #bleedingEdge> versions := self map values versions select: [ :version | '*baseline*' match: version name ]. ^ baselines detectMax: [ :version | version ]. the #bleedingEdgeVersion can be explicitly defined as follows (which then supercedes the default definition): bleedingEdgeVersion:spec <symbolicVersion: #bleedingEdge> spec for: #'common' version: 'baseline-1.0'. Soooo, instead of having a sliding definition of the 'default' version you would use #bleedingEdge instead of 'default' and when you add a new baseline version you just update the #bleedingEdge spec: bleedingEdgeVersion:spec <symbolicVersion: #bleedingEdge> spec for: #'common' version: 'baseline-1.0.1'. If I'm not mistaken this matches your proposed scenario, so I think (other than names) that symbolicVersions do address your needs... Dale |
|
|
Hi Dale,
Thanks for taking the time to re-explain the situation. I think I got it the first time, and I think that it would serve our purpose. However, as I mentioned before I do not really understand the difference between symbolicVersion and version. To my mind, you could achieve the same thing with just the concept of version. bleedingEdgeVersion: spec <version: 'bleedingEdgeVersion'> self baseline10: spec Or maybe there is something else I do not see. One thing I am not sure I understand is that you say that there will be a default #bleedingEdgeVersion. Will this imply that I have to subclass from somewhere, or will it be provided by the engine in a hardcoded way? And another thing: until we have a strong tool support, the problem is how to document what a developer should change. If you depend on the latest baseline, it means that you should find the latest baseline and then modify it. With default, we always know that we can modify it in place, and whenever we are happy with something we snapshot. However, it probably would be nice if every version would be immutable, but that requires tool support. Cheers, Doru On 8 Oct 2010, at 20:02, Dale Henrichs wrote: > On 08/06/2010 01: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? > > Doru, > > I am still wondering if you and I are on the same page with symbolicVersions and the 'default' convention. With symbolicVersions we have the notion of a #bleedingEdgeVersion by default defined as the latest #baseline version: > > bleedingEdgeVersion > <symbolicVersion: #bleedingEdge> > > versions := self map values versions select: [ :version | > '*baseline*' match: version name ]. > ^ baselines detectMax: [ :version | version ]. > > the #bleedingEdgeVersion can be explicitly defined as follows (which then supercedes the default definition): > > bleedingEdgeVersion:spec > <symbolicVersion: #bleedingEdge> > > spec for: #'common' version: 'baseline-1.0'. > > Soooo, instead of having a sliding definition of the 'default' version you would use #bleedingEdge instead of 'default' and when you add a new baseline version you just update the #bleedingEdge spec: > > bleedingEdgeVersion:spec > <symbolicVersion: #bleedingEdge> > > spec for: #'common' version: 'baseline-1.0.1'. > > If I'm not mistaken this matches your proposed scenario, so I think (other than names) that symbolicVersions do address your needs... > > Dale > > -- www.tudorgirba.com "One cannot do more than one can do." |
|
|
On 10/10/2010 04:07 AM, Tudor Girba wrote:
> Hi Dale, > > Thanks for taking the time to re-explain the situation. I think I got > it the first time, and I think that it would serve our purpose. No problem. It was unfortunate that you couldn't participate in the discussions at ESUG, so it is worth taking the time now to try to make sure that you understand the rationale. > > However, as I mentioned before I do not really understand the > difference between symbolicVersion and version. To my mind, you could > achieve the same thing with just the concept of version. > > bleedingEdgeVersion: spec <version: 'bleedingEdgeVersion'> self > baseline10: spec > > Or maybe there is something else I do not see. Ah yes. One thing that symbolicVersions provides (and the primary reason for it's existence) is the ability to specify a #stableVersion that is platform-dependent: stableVersion: spec <symbolicVersion: #stableVersion> spec for: #'common' version: '4.3'. spec for: #'pharo1.x' version: '4.0'. spec for: #'pharo1.0.x' version: '4.1'. spec for: #'pharo1.1.x' version: '4.2'. spec for: #'pharo1.2.x' version: '4.3'. The version #stableVersion can then be used to load the "known stable version" for a particular platform. Configs or load instructions can just tell folks to load the #stableVersion. This is superior to using #loadLatest because the latest version is not always the #stableVersion on a platform basis also there is no way to _specify_ #loadLatest in a configuration ... symbolicVersions makes it possible to specify the "latest stable version" in a configuration. The version #stableVersion can be used for projects like Seaside 3.0 and allow one to pick up the latest stable version of 3.0 ... meaning that configs that reference Seaside 3.0 wouldn't have to change just to pick up the latest stable version of Seaside3.0. Finally, I agree that you _could_ use a 'bleedingEdge' literalVersion, but doesn't this bring us back to your original post? If 'bleedingEdge' is a literalVersion then everyone would have to define a 'bleedingEdge' literal version which is not done today and probably wouldn't be done in the future (except for those projects that used the bleeding edge notion in development as is done in Moose). To me it is worth defining a default #bleedingEdge version (load the latest baseline version), since there don't have to be many interpretations of bleeding edge: "If you load the #bleedingEdgeVersion you may get unexpected behavior no matter what platform you load it on." Using #symbolicVersions for 'bleedingEdge' means that a definition will exist in every project and there is no need to call for a convention... > > One thing I am not sure I understand is that you say that there will > be a default #bleedingEdgeVersion. Will this imply that I have to > subclass from somewhere, or will it be provided by the engine in a > hardcoded way? This is yet to be determined. In fact, the notion of having any default behavior at all is still under discussion ... > > And another thing: until we have a strong tool support, the problem > is how to document what a developer should change. If you depend on > the latest baseline, it means that you should find the latest > baseline and then modify it. With default, we always know that we can > modify it in place, and whenever we are happy with something we > snapshot. However, it probably would be nice if every version would > be immutable, but that requires tool support. If you are actively using #bleedingEdgeVersion you _should_ have a #bleedingEdge: method in your config: bleedingEdgeVersion: spec <symbolicVersion: #bleedingEdgeVersion> spec for: #'common' version: '4.3-baseline'. Which you update when you add a new baseline ... very similar to using the 'default' version. the main exception is that #bleedingEdgeVersion is not just a convention, but part of the system and the #bleedingEdgeVersion can be used for external projects with confidence. BTW, using #symbolicVersions preserves the notion that literal versions are immutable (except for #developmentVersion which is mutable by definition) Dale |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |