GemStone Compatibility
Locked
 
|
> GemStone can't migrate an object that is on the stack (as a receiver), this means that the normal Magritte mechanism for creating variables doesn't work in GemStone...callers of readUsing: ... the solution for GemStone is to flip the logic:
I don't understand the problem. As far as I understand this only appears when the MAAutoSelectorAccessor is used. Magritte itself (with the exception of the respective test case) and Pier does not make use of this functionality. Personally I never use MAAutoSelectorAccessor, I rather use the refactoring tools. If nobody opposes I would propose to remove it? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
+1
I always thought that MAAutoSelectorAccessor is not really usefull! Cheers, Gerhard On Sun, May 17, 2009 at 10:41 PM, Lukas Renggli <[hidden email]> wrote: > GemStone can't migrate an object that is on the stack (as a receiver), this means that the normal Magritte mechanism for creating variables doesn't work in GemStone...callers of readUsing: ... the solution for GemStone is to flip the logic: _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
In reply to this post by Lukas Renggli
If a feature is there it will be used ... I made the changes in response to a bug report by a user.
If you get rid of it, I can toss those changes and while I'm at it, I will audit the other GemStone-specific changes and get back to you with the ones that are still problematic. Dale ----- "Lukas Renggli" <[hidden email]> wrote: | > GemStone can't migrate an object that is on the stack (as a | receiver), this means that the normal Magritte mechanism for creating | variables doesn't work in GemStone...callers of readUsing: ... the | solution for GemStone is to flip the logic: | | I don't understand the problem. As far as I understand this only | appears when the MAAutoSelectorAccessor is used. Magritte itself | (with | the exception of the respective test case) and Pier does not make use | of this functionality. | | Personally I never use MAAutoSelectorAccessor, I rather use the | refactoring tools. If nobody opposes I would propose to remove it? | | Cheers, | Lukas | | -- | Lukas Renggli | http://www.lukas-renggli.ch | _______________________________________________ | Magritte, Pier and Related Tools ... | https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
In reply to this post by Lukas Renggli
On Sun, 2009-05-17 at 22:41 +0200, Lukas Renggli wrote:
> > GemStone can't migrate an object that is on the stack (as a receiver), this means that the normal Magritte mechanism for creating variables doesn't work in GemStone...callers of readUsing: ... the solution for GemStone is to flip the logic: > > I don't understand the problem. As far as I understand this only > appears when the MAAutoSelectorAccessor is used. Magritte itself (with > the exception of the respective test case) and Pier does not make use > of this functionality. > > Personally I never use MAAutoSelectorAccessor, I rather use the > refactoring tools. If nobody opposes I would propose to remove it? > death. Never touched it again! I'm for removing, too! Norbert _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
In reply to this post by Dale
I think MAAutoAccessor is rarely useful, except when you want to
quickly prototype an application and generate inst-vars and accessors automatically. After the initial prototyping phase it is hardly useful to check for accessors and inst-vars on every read and write access. I removed it from the latest commit. If somebody really wants this feature, it can be easily retrieved from the history and packaged separately. Lukas On Sun, May 17, 2009 at 11:04 PM, Dale Henrichs <[hidden email]> wrote: > If a feature is there it will be used ... I made the changes in response to a bug report by a user. > > If you get rid of it, I can toss those changes and while I'm at it, I will audit the other GemStone-specific changes and get back to you with the ones that are still problematic. > > Dale > > > ----- "Lukas Renggli" <[hidden email]> wrote: > > | > GemStone can't migrate an object that is on the stack (as a > | receiver), this means that the normal Magritte mechanism for creating > | variables doesn't work in GemStone...callers of readUsing: ... the > | solution for GemStone is to flip the logic: > | > | I don't understand the problem. As far as I understand this only > | appears when the MAAutoSelectorAccessor is used. Magritte itself > | (with > | the exception of the respective test case) and Pier does not make use > | of this functionality. > | > | Personally I never use MAAutoSelectorAccessor, I rather use the > | refactoring tools. If nobody opposes I would propose to remove it? > | > | Cheers, > | Lukas > | > | -- > | Lukas Renggli > | http://www.lukas-renggli.ch > | _______________________________________________ > | Magritte, Pier and Related Tools ... > | https://www.iam.unibe.ch/mailman/listinfo/smallwiki > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: GemStone Compatibility
|
|
Excuse for my delay and for my english,
but i think MAAutoAccessor is very importan for " dinamic development ". I have a "database of descriptions " for define the base data of my application. For example descriptions about the items article, the contability data ecc... ecc. I don't know at begin, where i use this descriptions, but during the " life cicle of application" ( analisy, development, deployment, maintenance, integration.... ) it's very important use the reference to the database of description for define the "change". After this consideration, i think the MAAutoSelectorAccessor is a good solution for automatic instance varialble definition and accessor. When i do a reference to one description based on autoAccessor, the instanceVariable of the object is automatic update. In Gemstone maybe this support will can increase to manage object "compatibility" / "instance migration". Ciao, Dario >I think MAAutoAccessor is rarely useful, except when you want to > quickly prototype an application and generate inst-vars and accessors > automatically. After the initial prototyping phase it is hardly useful > to check for accessors and inst-vars on every read and write access. > > I removed it from the latest commit. If somebody really wants this > feature, it can be easily retrieved from the history and packaged > separately. > > Lukas > > On Sun, May 17, 2009 at 11:04 PM, Dale Henrichs > <[hidden email]> wrote: >> If a feature is there it will be used ... I made the changes in response >> to a bug report by a user. >> >> If you get rid of it, I can toss those changes and while I'm at it, I >> will audit the other GemStone-specific changes and get back to you with >> the ones that are still problematic. >> >> Dale >> _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
«
Return to Magritte, Pier and Related Tools
|
1 view|%1 views
| Free forum by Nabble | Edit this page |