Unified Property API and persistent properties (Pharo 5)
In Pharo 5 the "properties" API is unified (means you can associate properties to classes, methods, packages, ...). Really cool and a good step toward a unified and more flexible system. Exampel: |pck| pck := #'Foo-Kernel' asPackage. pck propertyAt: #'lastModified' put: DateAndTime now asString. pck propertyAt: #'generatedUsing' put: 'Pharo DynaCase'. pck properties So far it looks like the package properties are still transient - that means when you save the package and load in another image they will be empty again. Havent tried for class properties, ... Will this change in the near future so they are persistent? I wonder what the plans an next steps are in this area. Thanks T.
Hello, If we look at methods, properties are not persistent in the code. Pragmas are (which are âspecialâ kind of properties. We should do the same for all the other properties: the lower property level is not saved in source, so we can store *anything* there. But we can add a âhigher levelâ. E.g. some form of class Pragmas. And for packages, I would want to store what is now in the Manifest there and make *that* persistent (by storing it in the MCZ). This would a) make the whole Manifest mode much nicer, b) allow for true package comments and c) we would have a real place for Package meta-data. In general, we should move away from storing data just as arrays or strings in methods. Instead we should have a true model for the data and store that. In the same direction, we should find a way to store data like icons and other âfilesâ nicely⦠Marcus
On 08 Dec 2015, at 19:26, Torsten Bergmann <astares@gmx.de> wrote:
In Pharo 5 the "properties" API is unified (means you can associate properties to classes, methods, packages, ...). Really cool and a good step toward a unified and more flexible system.
Exampel:
|pck| pck := #'Foo-Kernel' asPackage. pck propertyAt: #'lastModified' put: DateAndTime now asString. pck propertyAt: #'generatedUsing' put: 'Pharo DynaCase'. pck properties
So far it looks like the package properties are still transient - that means when you save the package and load in another image they will be empty again. Havent tried for class properties, ...
Will this change in the near future so they are persistent? I wonder what the plans an next steps are in this area.
Thanks T.
> Hello, > > If we look at methods, properties are not persistent in the code. Pragmas are (which are > âspecialâ kind of properties. > > We should do the same for all the other properties: the lower property level is not saved > in source, so we can store *anything* there. > But we can add a âhigher levelâ. E.g. some form of class Pragmas. > > And for packages, I would want to store what is now in the Manifest there and make *that* > persistent (by storing it in the MCZ). > > This would a) make the whole Manifest mode much nicer, b) allow for true package comments > and c) we would have a real place for Package meta-data. + 1 > > In general, we should move away from storing data just as arrays or strings in methods. > Instead we should have a true model for the data and store that. > > In the same direction, we should find a way to store data like icons and other âfilesâ nicely⦠> > Marcus > >> On 08 Dec 2015, at 19:26, Torsten Bergmann <astares@gmx.de> wrote: >> >> In Pharo 5 the "properties" API is unified (means you can associate properties >> to classes, methods, packages, ...). Really cool and a good step toward a unified >> and more flexible system. >> >> Exampel: >> >> |pck| >> pck := #'Foo-Kernel' asPackage. >> pck propertyAt: #'lastModified' put: DateAndTime now asString. >> pck propertyAt: #'generatedUsing' put: 'Pharo DynaCase'. >> pck properties >> >> So far it looks like the package properties are still transient - that means >> when you save the package and load in another image they will be empty again. >> Havent tried for class properties, ... >> >> Will this change in the near future so they are persistent? I wonder what the >> plans an next steps are in this area. >> >> Thanks >> T. >> > >
On Wed, Dec 9, 2015 at 6:30 PM, stepharo <stepharo@free.fr> wrote:
Hello,
If we look at methods, properties are not persistent in the code. Pragmas are (which are âspecialâ kind of properties.
We should do the same for all the other properties: the lower property level is not saved in source, so we can store *anything* there. But we can add a âhigher levelâ. E.g. some form of class Pragmas.
And for packages, I would want to store what is now in the Manifest there and make *that* persistent (by storing it in the MCZ).
This would a) make the whole Manifest mode much nicer, b) allow for true package comments and c) we would have a real place for Package meta-data.
+ 1
Would storing these as STON within comments in methods be a cross dialect compatible way of maintaining properties across dialects that don't support properties like Pharo does? Otherwise another dialect loading a Monticello package and the saving may eliminate the properties. Or would this be more trouble than its worth? Otherwise maybe a tool to know a mcz was't saved by Pharo and helps go back through the ancestry to recover them. cheers -ben
In general, we should move away from storing data just as arrays or strings in methods. Instead we should have a true model for the data and store that.
In the same direction, we should find a way to store data like icons and other âfilesâ nicelyâ¦
Marcus
On 08 Dec 2015, at 19:26, Torsten Bergmann <astares@gmx.de> wrote:
In Pharo 5 the "properties" API is unified (means you can associate properties to classes, methods, packages, ...). Really cool and a good step toward a unified and more flexible system.
Exampel:
|pck| pck := #'Foo-Kernel' asPackage. pck propertyAt: #'lastModified' put: DateAndTime now asString. pck propertyAt: #'generatedUsing' put: 'Pharo DynaCase'. pck properties
So far it looks like the package properties are still transient - that means when you save the package and load in another image they will be empty again. Havent tried for class properties, ...
Will this change in the near future so they are persistent? I wonder what the plans an next steps are in this area.
Thanks T.
participants (4)
-
Ben Coman -
Marcus Denker -
stepharo -
Torsten Bergmann