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
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-tp3020788p... Sent from the Squeak - Beginners mailing list archive at Nabble.com. _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
On Sat, Oct 30, 2010 at 8:33 PM, Sean P. DeNigris sean@clipperadams.comwrote:
]]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.
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
Ralph Johnson wrote:
Yes, this is the Smalltalk way.
Thanks. It was actually a lot of fun to chop away large sections of the method.
Ralph Johnson wrote:
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.
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
beginners@lists.squeakfoundation.org
-
Levente Uzonyi -
Ralph Johnson -
Sean P. DeNigris