Symbol/String strategy

> Norbert,
>
> First off, I'd suggest that you investigate your test cases. In my experience the actual code works correctly ... the code produces and uses Symbol, for example, but the tests often end up using strings ("incorrectly") in creating test cases, which cause the tests to fail...
>
> If it is your dummy data for tests that is introducing Strings, you might want to convert them to use Symbols ("correctly").
>
> If the code itself is inconsistent, then I'd be inclined to root out the source of the Strings and fix it (especially if the code is already a gemstone-specific version). Since you're dealing with XML, that means that the #asSymbol would be "correctly" inserted shortly after the token was recognized as an element name....
>
> With all of that said, you're solution will certainly work well enough and is probably less intrusive in the code ... which makes it a bit easier to maintain.
>
> Dale
>
>
> ----- "Norbert Hartl" <[hidden email]> wrote:
>
> | I develop on pharo and deploy on gemstone. There is one thing I
> | discovered right now because my test cases worked in pharo but not in
> | gemstone.
> |
> | I just learned that
> |
> | #hello = 'hello'
> |
> | is true in pharo and false in gemstone. I don't want to discuss
> | equality of strings and symbols in general but rather what approach to
> | take for my code. XMLSupport manages the xml element names with
> | symbols. To use XMLNodeWithElements>>elementAt: I have to specify a
> | symbol as an argument. Now I'm thinking about where to assure it is a
> | symbol.
> |
> | I personally would think that
> |
> | elementAt: entityName
> | ^self elementAt: entityName ifAbsent: [nil]
> |
> | should be
> |
> | elementAt: entityName
> | ^self elementAt: entityName asSymbol ifAbsent: [nil]
> |
> | because it expects a symbol so it should do the best that it can.
> |
> | What do you think?
> |
> | Norbert