[Seaside-dev] Issue 289 in seaside: Changes to Seaside-Tests-Core to address issues discovered in GemStone port

[codesite-noreply at google.com]

Comment #5 on issue 289 by WeybridgeWay: Changes to Seaside-Tests-Core to  
address issues discovered in GemStone port
http://code.google.com/p/seaside/issues/detail?id=289

Philippe,
Could you please help me understand your insistence on keeping  
Squeak-specific code in what should be portable code?

You allude to a general issue of how WAFileLibrary handles things and seem  
to be implying that the hard-coded method you want in WATestingFiles  
represents
how all methods in WAFileLibrary will be generated. You seem to suggest  
that if other platforms can't handle this approach, then they will be  
unable to handle
WAFileLibrary, so the test is best as you have it.

As I read the code, WAFileLibrary has an #'addFile:' method that use  
class-side methods such as #'compileText:selector:'. As I read these  
methods, they make
calls to WAPlatform>>#'asMethodReturningByteArray:named:' and  
WAPlatform>>#'compile:into:classified:'. Notwithstanding your apparent  
preference for the
Squeak implementation of  
WASqueakPlatform>>#'asMethodReturningByteArrayWithCache:named:', I don't  
see that other platforms will be required to take this
approach.

Is it possible that the refactoring that you were anticipating has already  
been done and the troublesome method is a hold-over from before that hasn't  
yet been
converted to the new approach?

It seems much easier to just use the simple code I wrote in the  
WATestingFiles. An alternative that seems in the spirit of the new approach  
would be to have the
test #setUp code add the needed files to the default library. This would  
allow the various platforms to generate the method in their preferred  
manner. I can
imagine that this could appear to some as being more elegant, but can't see  
how it would really be worth the trouble.

I'd like to put back my fix, but I feel like redoing a change that you  
undid would be inappropriate (though I'm annoyed at your removing my fix  
based on what
appears to me to be an incorrect understanding of how things work--was it  
so important to undo my change without further discussion?). Thus, I'll  
wait till you
or someone else can help me come up with a way to get this Squeak-specific  
code out of the shared package. Until then I'm going to have to live with  
failing
tests, and that reduces my incentive to continue this cleanup effort.

--James Foster

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings