(redirecting to vm-dev)
On Thu, May 13, 2010 at 4:41 PM, Igor Stasenko siguctua@gmail.com wrote:
Just want to share my experience working with Interpreter/ interpreterProxy api using VMMaker.
Make a guess (and answer quickly, in what direction each of these methods doing conversion)
positive32BitValueOf: positive32BitIntegerFor:
got the answer?
valueOf: takes a Smalltalk object and returns a 32-bit C value. IntegerFor: takes a 32-bit C value and answers a Smalltalk object. I find these natural :)
Things I *hate* are nasty gotchers in Slang like self sizeof: #sqLong which translates to (sizeof("sqLong")) You have to write self sizeof: #sqLong asSymbol to get (sizeof(sqLong)) (ouch).
I'd fix this but IIRC there are plugins that use this. Ho hum. Some time we need to rationalize Slang and throw out some of the more evil traps such as the above.
These methods along with other xxxIntegerFor: and xxxValueOf:
used most frequently in primitive conversion code. And i am really sick of such naming..
Why not create some more comprehensible aliases for your own use and get e.g. Slang to translate them to the form you find hard to distinguish?
-- Best regards, Igor Stasenko AKA sig.
On 14 May 2010 03:48, Eliot Miranda eliot.miranda@gmail.com wrote:
(redirecting to vm-dev)
On Thu, May 13, 2010 at 4:41 PM, Igor Stasenko siguctua@gmail.com wrote:
Just want to share my experience working with Interpreter/ interpreterProxy api using VMMaker.
Make a guess (and answer quickly, in what direction each of these methods doing conversion)
positive32BitValueOf: positive32BitIntegerFor:
got the answer?
valueOf: takes a Smalltalk object and returns a 32-bit C value. IntegerFor: takes a 32-bit C value and answers a Smalltalk object. I find these natural :)
good for you. :) I lazy typing, so i usually typing the first few letters and then using alt-q to autocomplete the selector. And sometimes i picking a wrong method, because for me, they are not so different.. integer is also a value.. you know :)
Things I *hate* are nasty gotchers in Slang like self sizeof: #sqLong which translates to (sizeof("sqLong"))
yeah, that's why i introduced self cIdentifier: #sqLong
in Hydra. So, its just puts this symbol in source without any transformations.
You have to write self sizeof: #sqLong asSymbol to get (sizeof(sqLong)) (ouch). I'd fix this but IIRC there are plugins that use this. Ho hum. Some time we need to rationalize Slang and throw out some of the more evil traps such as the above.
These methods along with other xxxIntegerFor: and xxxValueOf: used most frequently in primitive conversion code. And i am really sick of such naming..
Why not create some more comprehensible aliases for your own use and get e.g. Slang to translate them to the form you find hard to distinguish?
Yeah... i could do that. But you know.. i'm not a big fan of aliased methods.
NBInterpreterProxy methodDict size 149
if i start adding aliases, it will go an go more and more. And, usually, the more things you adding , the harder to figure out, what you need.
-- Best regards, Igor Stasenko AKA sig.
Why not create some more comprehensible aliases for your own use and get e.g. Slang to translate them to the form you find hard to distinguish?
Yeah... i could do that. But you know.. i'm not a big fan of aliased methods.
NBInterpreterProxy methodDict size 149
if i start adding aliases, it will go an go more and more. And, usually, the more things you adding , the harder to figure out, what you need.
But igor this is a really good idea to migrate slowly API. You have the old and you build slowly the new, but on the side of the old and you slowly replace the old senders and remove the old API. Now if you do not design the new then the old will stay there forever. So please start proposing a new API.
Stef
On 14 May 2010 09:56, stephane ducasse stephane.ducasse@gmail.com wrote:
Why not create some more comprehensible aliases for your own use and get e.g. Slang to translate them to the form you find hard to distinguish?
Yeah... i could do that. But you know.. i'm not a big fan of aliased methods.
NBInterpreterProxy methodDict size 149
if i start adding aliases, it will go an go more and more. And, usually, the more things you adding , the harder to figure out, what you need.
But igor this is a really good idea to migrate slowly API. You have the old and you build slowly the new, but on the side of the old and you slowly replace the old senders and remove the old API. Now if you do not design the new then the old will stay there forever. So please start proposing a new API.
This makes sense. Thanks for opening my eyes :)
Stef
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Igor Stasenko -
stephane ducasse