Administrator
|
I'm talking to Ruby via XMLRPC using the XMLRPC package from SqS.
The library has this heinous case statement: val caseOf: { [True] -> [^ self wrapVal: '1' type: 'boolean']. [true] -> [^ self wrapVal: '1' type: 'boolean']. [False] -> [^ self wrapVal: '0' type: 'boolean']. [false] -> [^ self wrapVal: '0' type: 'boolean']. } otherwise: [ (val class) caseOf: { [SmallInteger] -> [^ self wrapVal: val asString type: 'i4']. [Float] -> [^ self wrapVal: val asString type: 'double']. [String] -> [^ self wrapVal: (self normalize: val)]. [ByteString] -> [^ self wrapVal: (self normalize: val)]. [XMLRPCDateTime] -> [^ self wrapVal: val encodeISO8601 type: 'dateTime.iso8601']. [Array] -> [^ self wrapVal: (self encodeArray: val) type: 'array']. [Dictionary] -> [^ self wrapVal: (self encodeStruct: val) type: 'struct']. } otherwise: [ val isStream ifTrue: [^ self wrapVal: (Base64MimeConverter mimeEncode: val) contents type: 'base64'] ifFalse: "Unhandled type." [XMLRPCException signal: 'Unhandled type: ' , val className]. ]] I was thinking how beautiful this code could be if each class had it's own encode method, like: In method protocol *xmlrpc Symbol>>encodeForXmlRpc String>>encodeForXmlRpc etc. BONUS: if this was the case, extending for new types would be ridiculously trivial - just add the method to the type instead of trying to hook into large control structures, e.g. * so that a Symbol on the ST end is recognized as a Symbol on the Ruby side (ends up as a string right now) *so that I can talk to remote Ruby objects OTOH, I was concerned about cluttering the core classes. I've been going back and forth with this kind of thing since I came to Smalltalk, never got it resolved. What do you think? Thanks. Sean
Cheers,
Sean |
On Sat, 30 Oct 2010, Sean P. DeNigris wrote:
snip > I was thinking how beautiful this code could be if each class had it's own > encode method, like: > In method protocol *xmlrpc > Symbol>>encodeForXmlRpc > String>>encodeForXmlRpc > etc. > > BONUS: if this was the case, extending for new types would be ridiculously > trivial - just add the method to the type instead of trying to hook into > large control structures, e.g. > * so that a Symbol on the ST end is recognized as a Symbol on the Ruby side > (ends up as a string right now) > *so that I can talk to remote Ruby objects > > OTOH, I was concerned about cluttering the core classes. I've been going > back and forth with this kind of thing since I came to Smalltalk, never got > it resolved. > > What do you think? I agree with you. :) Core classes won't be cluttered, because you'll add only 1-2 methods to a separate method category. Btw XML-RPC is so simple that it could be reimplemented in an hour. Levente > > Thanks. > Sean > -- > View this message in context: http://forum.world.st/OOP-Question-adding-methods-to-core-classes-tp3020788p3020788.html > Sent from the Squeak - Beginners mailing list archive at Nabble.com. > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners > Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by Sean P. DeNigris
On Sat, Oct 30, 2010 at 8:33 PM, Sean P. DeNigris <[hidden email]> wrote:
]] Yes, this is the Smalltalk way. When you add a method to existing classes, you want to try to avoid name clashes. Pick a name that nobody else is likely to use. encodeForXmlRpc is a good name for that reason.
-Ralph Johnson _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Administrator
|
Thanks. It was actually a lot of fun to chop away large sections of the method. Yeah, I went down that little path, where I kept the "encode" name and then thought, "hmm... not a good name for a method on a core class" Sean
Cheers,
Sean |
Free forum by Nabble | Edit this page |