I am get annoyed by these numbers.. why, living in our amazingly powerful smalltalk world, in order to see what the primitive does, i should first lookup the selector in #initializePrimitiveTable method? Is it so hard for compiler to lookup the prim by its symbolic name , why i forced to do that manually all the time? Just out of curiosity, can anyone say (without looking into image), what <primitive: 135> does? And now, same question, what <primitive: #primitiveMillisecondClock> does? Never ending fight: meaningful names vs meaningless numbers -- Best regards, Igor Stasenko. |
Am 2012-03-10 um 12:08 schrieb Igor Stasenko: > > I am get annoyed by these numbers.. > why, living in our amazingly powerful smalltalk world, in order to see > what the primitive does, > i should first lookup the selector in #initializePrimitiveTable method? > > Is it so hard for compiler to lookup the prim by its symbolic name , > why i forced to do that manually all the time? > > Just out of curiosity, can anyone say (without looking into image), what > <primitive: 135> does? > And now, same question, what > <primitive: #primitiveMillisecondClock> > does? > > Never ending fight: meaningful names vs meaningless numbers > And while we are at it, Can we devise a more comprehensible variant of denoting the core primitives than "Essential." in the comment of methods using them? (this one gave me shivers…) Best -Tobias |
On 10 March 2012 13:37, Tobias Pape <[hidden email]> wrote: > > > Am 2012-03-10 um 12:08 schrieb Igor Stasenko: > >> >> I am get annoyed by these numbers.. >> why, living in our amazingly powerful smalltalk world, in order to see >> what the primitive does, >> i should first lookup the selector in #initializePrimitiveTable method? >> >> Is it so hard for compiler to lookup the prim by its symbolic name , >> why i forced to do that manually all the time? >> >> Just out of curiosity, can anyone say (without looking into image), what >> <primitive: 135> does? >> And now, same question, what >> <primitive: #primitiveMillisecondClock> >> does? >> >> Never ending fight: meaningful names vs meaningless numbers >> > > And while we are at it, > Can we devise a more comprehensible variant of denoting > the core primitives than "Essential." in the comment > of methods using them? (this one gave me shivers…) > Well this is a bit orthogonal to what i proposing. My proposal is to change compiler & all numbered prim invocations to be more accessible, while yours is about better documenting of "what is a primitive". I'm not saying that this is not important, but requires a bit different skill(s) for the task: writing, not coding :) > Best > -Tobias -- Best regards, Igor Stasenko. |
In reply to this post by Igor Stasenko
On 3/10/2012 12:08, Igor Stasenko wrote: > I am get annoyed by these numbers.. > why, living in our amazingly powerful smalltalk world, in order to see > what the primitive does, > i should first lookup the selector in #initializePrimitiveTable method? > > Is it so hard for compiler to lookup the prim by its symbolic name , > why i forced to do that manually all the time? > > Just out of curiosity, can anyone say (without looking into image), what > <primitive: 135> does? > And now, same question, what > <primitive: #primitiveMillisecondClock> > does? > > Never ending fight: meaningful names vs meaningless numbers Easy: Just do the same thing the compiler does with messages that it has specialized bytecodes for. I.e., add a class var to the compiler containing names and indicees for indexed prims and make it so that the compiler knows that it can replace primitiveFoo with prim index 123. Do the opposite in the decompiler and voila! you're done. Shouldn't take more than a day to do that, really. Cheers, - Andreas |
On 10 March 2012 18:56, Andreas Raab <[hidden email]> wrote: > > On 3/10/2012 12:08, Igor Stasenko wrote: >> >> I am get annoyed by these numbers.. >> why, living in our amazingly powerful smalltalk world, in order to see >> what the primitive does, >> i should first lookup the selector in #initializePrimitiveTable method? >> >> Is it so hard for compiler to lookup the prim by its symbolic name , >> why i forced to do that manually all the time? >> >> Just out of curiosity, can anyone say (without looking into image), what >> <primitive: 135> does? >> And now, same question, what >> <primitive: #primitiveMillisecondClock> >> does? >> >> Never ending fight: meaningful names vs meaningless numbers > > > Easy: Just do the same thing the compiler does with messages that it has > specialized bytecodes for. I.e., add a class var to the compiler containing > names and indicees for indexed prims and make it so that the compiler knows > that it can replace primitiveFoo with prim index 123. Do the opposite in the > decompiler and voila! you're done. Shouldn't take more than a day to do > that, really. > I just can't understand why highly intellectual people, who able to hack VM seems to be loving practicing self-torturing, like in this example. :) > Cheers, > - Andreas > -- Best regards, Igor Stasenko. |
On 3/10/2012 19:15, Igor Stasenko wrote: > Yes, of course it is easy. I just can't understand why highly > intellectual people, who able to hack VM seems to be loving practicing > self-torturing, like in this example. :) Not sure what you mean. I don't recall if I *ever* had the need to know what an index prim maps to but if I had to do this more than three times in a week I almost certainly would write the code I just described. The history of primitives is such that indexed prims were first, then named prims were added and that's why there are indexed and named prims side by side. This could of course be unified along the lines we're talking about but I fail to see why not doing this would be self-torturing, given that apparently nobody is bothered by it. And if this just happens to be bothering you, then you're in a perfect situation to fix it. Cheers, - Andreas |
In reply to this post by Igor Stasenko
Am 10.03.2012 12:08, schrieb Igor Stasenko: > Just out of curiosity, can anyone say (without looking into image), what > <primitive: 135> does? > And now, same question, what > <primitive: #primitiveMillisecondClock> > does? > > Never ending fight: meaningful names vs meaningless numbers > > Since a primitive is typically a low-level implementation of a method (whose name, comment and maybe primitive failure code should state what it actually does), there's not really a guessing game. Granted, your suggestion would make it look a little nicer, so if you just want to implement it, it would probably be accepted easily. However, I don't see it as a most pressing problem... Cheers, Hans-Martin |
On 10 March 2012 22:22, Hans-Martin Mosner <[hidden email]> wrote: > > Am 10.03.2012 12:08, schrieb Igor Stasenko: >> Just out of curiosity, can anyone say (without looking into image), what >> <primitive: 135> does? >> And now, same question, what >> <primitive: #primitiveMillisecondClock> >> does? >> >> Never ending fight: meaningful names vs meaningless numbers >> >> > Since a primitive is typically a low-level implementation of a method (whose name, comment and maybe primitive failure > code should state what it actually does), there's not really a guessing game. > Granted, your suggestion would make it look a little nicer, so if you just want to implement it, it would probably be > accepted easily. However, I don't see it as a most pressing problem... > It is not a pressing problem, unless you see it at larger scale, because this is not a single place in system, where you can find use of numeric constants. Instead of abstractions, numbers turning us into computers who should remember strange numbers and their meaning in various different contexts, making code brittle and error prone, wasting our time and effort, but worst of all, making newbies sitting clueless, what are those numbers mean, what is connection between their values and code logic. Every time when you use a numeric constant - a little cute animal dies. :) -- Best regards, Igor Stasenko. |
In reply to this post by Igor Stasenko
On Sat, Mar 10, 2012 at 12:08:08PM +0100, Igor Stasenko wrote: > > I am get annoyed by these numbers.. > why, living in our amazingly powerful smalltalk world, in order to see > what the primitive does, > i should first lookup the selector in #initializePrimitiveTable method? > > Is it so hard for compiler to lookup the prim by its symbolic name , > why i forced to do that manually all the time? > > Just out of curiosity, can anyone say (without looking into image), what > <primitive: 135> does? > And now, same question, what > <primitive: #primitiveMillisecondClock> > does? > > Never ending fight: meaningful names vs meaningless numbers > So for <primitive: 135> I would do "Interpreter browsePrimitive: 135". Dave Interpreter class-*DTL.st (1K) Download Attachment |
On 10 March 2012 23:12, David T. Lewis <[hidden email]> wrote: > > On Sat, Mar 10, 2012 at 12:08:08PM +0100, Igor Stasenko wrote: >> >> I am get annoyed by these numbers.. >> why, living in our amazingly powerful smalltalk world, in order to see >> what the primitive does, >> i should first lookup the selector in #initializePrimitiveTable method? >> >> Is it so hard for compiler to lookup the prim by its symbolic name , >> why i forced to do that manually all the time? >> >> Just out of curiosity, can anyone say (without looking into image), what >> <primitive: 135> does? >> And now, same question, what >> <primitive: #primitiveMillisecondClock> >> does? >> >> Never ending fight: meaningful names vs meaningless numbers >> > > FWIW here is what I use (attached). > > So for <primitive: 135> I would do "Interpreter browsePrimitive: 135". > 'Interpreter browsePrimitive:' expression in order to get there, and you have to type it. It saves you a bit of time, since now you don't have to manually lookup the table While in my case, you don't have to remember anything and just press implementors of it. > Dave > > -- Best regards, Igor Stasenko. |
In reply to this post by Igor Stasenko
Great idea! But let's not stop there: how about getting rid of classes, too? - David (Don't worry if you don't get it.) On Mar 10, 2012, at 3:08 AM, Igor Stasenko wrote: > > I am get annoyed by these numbers.. > why, living in our amazingly powerful smalltalk world, in order to see > what the primitive does, > i should first lookup the selector in #initializePrimitiveTable method? > > Is it so hard for compiler to lookup the prim by its symbolic name , > why i forced to do that manually all the time? > > Just out of curiosity, can anyone say (without looking into image), what > <primitive: 135> does? > And now, same question, what > <primitive: #primitiveMillisecondClock> > does? > > Never ending fight: meaningful names vs meaningless numbers > > > -- > Best regards, > Igor Stasenko. |
On 2012-03-12, at 06:32, [hidden email] wrote: > > Great idea! But let's not stop there: how about getting rid of classes, too? > > - David (Don't worry if you don't get it.) shush, damn selfers :D > On Mar 10, 2012, at 3:08 AM, Igor Stasenko wrote: > >> >> I am get annoyed by these numbers.. >> why, living in our amazingly powerful smalltalk world, in order to see >> what the primitive does, >> i should first lookup the selector in #initializePrimitiveTable method? >> >> Is it so hard for compiler to lookup the prim by its symbolic name , >> why i forced to do that manually all the time? >> >> Just out of curiosity, can anyone say (without looking into image), what >> <primitive: 135> does? >> And now, same question, what >> <primitive: #primitiveMillisecondClock> >> does? >> >> Never ending fight: meaningful names vs meaningless numbers please please please! :D and when we're already at it: give proper names to exported methods by replaceing $: in st method names with $_ in c names; st: getPath: length: c: getPathLength() # totally obstructed name! getPath_length_() # much better in my eyes this would make it much easier to find the corresponding methods on ST code... (maybe we should add some source link in the generated source code getPathLength(....) { #define __FILE__ VMVMaker >> #getPath:length: .... best cami |
Free forum by Nabble | Edit this page |