[Pharo-project] Class rename on materialization
Hi. We have recently discussed in a couple of threads about serialization & class renames. I want to ask you for the following case, because I'm not sure what should be the expected result. Suppose we serialize: Array with: OldClass new with: OldClass with: #OldClass. Then, we specify to the materializer that OldClass has been renamed to NewClass. Now, should we expect that result first -------> a NewClass second --> NewClass third ------> #NewClass or... result third ------> #OldClass ? In other words, should a class rename affect to every symbol in the graph? Thanks, MartÃn
so guys??? Should we only renames Classes/Traits/ClassPools/Methods or we directly rename all ocurrences of a symbol ? On Thu, Dec 15, 2011 at 6:32 AM, Martin Dias <tinchodias@gmail.com> wrote:
Hi. We have recently discussed in a couple of threads about serialization & class renames. I want to ask you for the following case, because I'm not sure what should be the expected result.
Suppose we serialize:
Array with: OldClass new with: OldClass with: #OldClass.
Then, we specify to the materializer that OldClass has been renamed to NewClass.
Now, should we expect that
result first -------> a NewClass second --> NewClass third ------> #NewClass
or...
result third ------> #OldClass
?
In other words, should a class rename affect to every symbol in the graph?
Thanks, MartÃn
-- Mariano http://marianopeck.wordpress.com
On 16/12/11 3:09 PM, Mariano Martinez Peck wrote:
so guys??? Should we only renames Classes/Traits/ClassPools/Methods or we directly rename all ocurrences of a symbol ?
I haven't any use cases to decide. If you want a guess, then I'd say leave the symbols unchanged, because it's simpler to implement. Since there's no data points, at this point, why do work that may prove to be unnecessary.
On Sat, Dec 17, 2011 at 2:44 AM, Yanni Chiu <yanni@rogers.com> wrote:
On 16/12/11 3:09 PM, Mariano Martinez Peck wrote:
so guys??? Should we only renames Classes/Traits/ClassPools/**Methods or we directly rename all ocurrences of a symbol ?
I haven't any use cases to decide. If you want a guess, then I'd say leave the symbols unchanged, because it's simpler to implement. Since there's no data points, at this point, why do work that may prove to be unnecessary.
Well, so I guess we will change just the classes and traits, and not every symbol. I was in favor of renaming every symbol because the "class rename" refactoring changes any method who mention the original name. Thanks! Martin
On 17/12/11 9:28 PM, Martin Dias wrote:
Well, so I guess we will change just the classes and traits, and not every symbol.
I was in favor of renaming every symbol because the "class rename" refactoring changes any method who mention the original name.
That's a reference to a class, by its global name, and it's the right thing to rename it when refactoring. Now I'm not sure what is meant by "renaming every symbol". Is there some structure in a compiled method (which holds a class name symbol) which is going to be renamed? Or, are you talking about any serialized symbol, which happened to be the same as the class to be renamed, would be renamed? Or are both these scenarios the same?
On Sun, Dec 18, 2011 at 12:05 AM, Yanni Chiu <yanni@rogers.com> wrote:
On 17/12/11 9:28 PM, Martin Dias wrote:
Well, so I guess we will change just the classes and traits, and not every symbol.
I was in favor of renaming every symbol because the "class rename" refactoring changes any method who mention the original name.
That's a reference to a class, by its global name, and it's the right thing to rename it when refactoring.
Now I'm not sure what is meant by "renaming every symbol". Is there some structure in a compiled method (which holds a class name symbol) which is going to be renamed? Or, are you talking about any serialized symbol, which happened to be the same as the class to be renamed, would be renamed? Or are both these scenarios the same?
For example, in the method Object >> arrayWithSomething ^Array with: OldClass with: #OldClass if you inspect Object >> #arrayWithSomething, in the literals you will see: - for the first array element, an association #OldClass->OldClass, which is an entry in Smalltalk globals. This association should be materialized as #NewClass->NewClass. - for the second array element, the symbol #OldClass. Here is my dubt: 1) materialize as #NewSymbol or 2) as #OldSymbol? 1) I think in this case we want to materialize the method as: arrayWithSomething ^Array with: NewClass with: #NewClass But... 2) suppose that in the same file we serialized some other object (not the above mentioned method) who points to the symbol #OldClass. Maybe we don't want to rename the symbol in this case.
On 17/12/11 11:00 PM, Martin Dias wrote:
For example, in the method
Object >> arrayWithSomething ^Array with: OldClass with: #OldClass
if you inspect Object >> #arrayWithSomething, in the literals you will see: - for the first array element, an association #OldClass->OldClass, which is an entry in Smalltalk globals. This association should be materialized as #NewClass->NewClass.
Yes, it should be mapped, in that case. Now, the feature is a renaming of Smalltalk globals, not just classes, if it's implemented in this way, for method literals.
- for the second array element, the symbol #OldClass. Here is my dubt: 1) materialize as #NewSymbol or 2) as #OldSymbol?
1) I think in this case we want to materialize the method as:
arrayWithSomething ^Array with: NewClass with: #NewClass
Without other information, there's no way in general to know that #OldClass is meant to refer to the OldClass class. IMHO, it's better to leave it alone, in that case. There's usually a facade that would construct the class names from parameters, or the class is known by a fixed name. Trying to address a problem that doesn't occur in real code, might cause other problems.
2) suppose that in the same file we serialized some other object (not the above mentioned method) who points to the symbol #OldClass. Maybe we don't want to rename the symbol in this case.
I think it's better to leave it alone, in this case too.
participants (3)
-
Mariano Martinez Peck -
Martin Dias -
Yanni Chiu