17 May
2009
17 May
'09
10:41 p.m.
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
17 May
17 May
10:56 p.m.
+1
I always thought that MAAutoSelectorAccessor is not really usefull!
Cheers,
Gerhard
On Sun, May 17, 2009 at 10:41 PM, Lukas Renggli <renggli(a)gmail.com> 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
11:04 p.m.
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" <renggli(a)gmail.com> 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
11:13 p.m.
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
<dale.henrichs(a)gemstone.com> 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" <renggli(a)gmail.com> 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
18 May
18 May
3:22 p.m.
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
<dale.henrichs(a)gemstone.com> 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
>
://www.iam.unibe.ch/mailman/listinfo/smallwiki
17 May
17 May
11:11 p.m.
On Sun, 2009-05-17 at 22:41 +0200, Lukas Renggli wrote:
I used it in the beginning. Than the black magic scared me to
death. Never touched it again!
I'm for removing, too!
Norbert
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?
5455
days inactive
5456
days old
5 comments
5 participants
participants (5)
-
Dale Henrichs -
Dario Trussardi -
Gerhard Obermann -
Lukas Renggli -
Norbert Hartl