Dec. 9, 2015
10:30 a.m.
> 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. >> > >