[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-smalltalk] .st file naming
From: |
Holger Hans Peter Freyther |
Subject: |
Re: [Help-smalltalk] .st file naming |
Date: |
Tue, 7 Apr 2015 15:52:38 +0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Tue, Apr 07, 2015 at 08:35:44AM +0100, Jan Vrany wrote:
> Well, you can still have a Cypress reader/writer (which is a format of a
> (git)filetree - https://github.com/CampSmalltalk/Cypress ) and
> use it to import/export.
> In my experience, as of today it's still much simpler just to port
> monticello and read/save to monticello when one has to work
> with Pharo/Squeak code.
Yes, I started twice with porting Monticello and didn't
complete it. Did you get further? Did you start with Pharo
or the Gemstone/S version? What do you do with traits and
other items we don't support yet? How to resolve a conflict
when loading?
> Yes, each method and package should know its package. In a future,
> each instvar and annotation too, but we're not yet there (no smalltalk
> is).
>
> I would strongly suggest to keep that within Class and CompiledMethod
> instances. Doing it otherwise (i.e., registry) is just unnecessary
> complication because then you must make sure you are always in sync.
> This is tricky to do, Pharo's RPackage is a an example of it.
> Another complication would come into the play if you - as you suggested
> - would like to have it as non-kernel loadable package. Then you somehow
> would have to initialize the registry so also a kernel methods and all
> packages that happen to be loaded before are properly packaged. Tricky
> given that the goal of the "registry" package is to track packages :-)
I would have simply marked everything as "kernel" that is loaded
before the registry package. The benefit of a registry is that
depending on your storage structure you don't need to walk all
classes/compiled methods to find the ones that belong to a package.
> The only reason for having it external in "registry" package I can think
> of is a memory consideration - no "registry" package loaded, less memory
> consumed. BUT: for deployment on memory constrained systems you can
> always drop complete MethodInfo (held by CompiledMethod) to save memory.
> Similar trick could be done for classes by introducing "ClassInfo" class
> which would keep
> package, category, and so on. This way, you save even more memory.
>
> Does it make sense?
yes, it does counter my argument of just having an "external"
registry. Let's see if Paolo comments on "ClassInfo".
holger
- [Help-smalltalk] .st file naming, Jan Vrany, 2015/04/03
- Re: [Help-smalltalk] .st file naming, Holger Hans Peter Freyther, 2015/04/03
- Message not available
- Re: [Help-smalltalk] .st file naming, Jan Vrany, 2015/04/07
- Re: [Help-smalltalk] .st file naming, Holger Hans Peter Freyther, 2015/04/07
- Re: [Help-smalltalk] .st file naming, Jan Vrany, 2015/04/07
- Re: [Help-smalltalk] .st file naming, Jan Vrany, 2015/04/08
- Re: [Help-smalltalk] .st file naming, Holger Freyther, 2015/04/12
Re: [Help-smalltalk] .st file naming, Paolo Bonzini, 2015/04/03