On 11 October 2012 19:26, Bert Freudenberg bert@freudenbergs.de wrote:
On 11.10.2012, at 03:54, Igor Stasenko siguctua@gmail.com wrote:
If/when you hit that limit, you can always refactor the code to use dictionary to hold/cache parsers instead of inst vars.
It's a pain in the neck having to deal with this. Also, you lose an order of magnitude in efficiency, unless you support both styles and only flow over into dictionaries when needed. Makes the code way more complicated. Also, debugging is not as nice as with real variables. Etc.
I disagree. You have problems in a first place because of bloat. When you have over 255 variables to track, it makes little difference for humans how are they stored. Please do not mix cause and effect together. Human brains is simply do not fit for accounting that much information, and there is no way how humans can make sense out of so much various state grouped into a single entity. Not saying about unbearable complexity of code which needs to manage that amount of state meaningfully inside a single entity.
If language allows you to do something, it doesn't means you should do it and exploit it up to the point of total absurd. (STL and especially Boost C++ libraries is a good example of such abuses :)
And yes, for a simple demonstration, can you compare following two snippets of code and say, which one is more bearable/readable and easier to work with:
Object subclass: #Point instanceVariableNames: 'x y' classVariableNames: '' poolDictionaries: '' category: 'Kernel-BasicObjects'
----- ObjectMemory subclass: #Interpreter instanceVariableNames: 'activeContext theHomeContext method receiver instructionPointer stackPointer localIP localSP localHomeContext localReturnContext localReturnValue messageSelector argumentCount newMethod currentBytecode successFlag primitiveIndex primitiveFunctionPointer methodCache atCache lkupClass reclaimableContextCount nextPollTick nextWakeupTick lastTick interruptKeycode interruptPending semaphoresToSignalA semaphoresUseBufferA semaphoresToSignalCountA semaphoresToSignalB semaphoresToSignalCountB savedWindowSize fullScreenFlag deferDisplayUpdates pendingFinalizationSignals compilerInitialized extraVMMemory receiverClass interpreterProxy showSurfaceFn interruptCheckCounterFeedBackReset interruptChecksEveryNms externalPrimitiveTable primitiveTable globalSessionID jmpBuf jmpDepth jmpMax suspendedCallbacks suspendedMethods profileProcess profileMethod profileSemaphore nextProfileTick metaclassSizeBytes statIOProcessEvents statCheckForEvents statQuickCheckForEvents statProcessSwitch statPendingFinalizationSignals gcSemaphoreIndex' classVariableNames: 'AtCacheEntries AtCacheFixedFields AtCacheFmt AtCacheMask AtCacheOop AtCacheSize AtCacheTotalSize AtPutBase BlockArgumentCountIndex BlockMethodIndex BytecodeTable CacheProbeMax CallerIndex ClosureMethodIndex CompilerHooksSize CrossedX DirBadPath DirEntryFound DirNoMoreEntries DoBalanceChecks EndOfRun HomeIndex InitialIPIndex JitterTable MaxExternalPrimitiveTableSize MaxJumpBuf MaxPrimitiveIndex MillisecondClockMask PrimitiveExternalCallIndex PrimitiveTable SemaphoresToSignalSize TempFrameStart' poolDictionaries: 'VMBasicConstants VMMethodCacheConstants VMObjectIndices' category: 'VMMaker-Interpreter'
-------- you know, sometimes for me it even hard to tell whether i need to add a new state variable or there's already some variable what i can reuse.. neither i can clearly tell, what the purpose of each and every of variables in that bloated class without spending a considerable amount of time groking the code.
And do you really think that debugging its code would be significantly easier comparing if that state would be held in dictionary?
The code limits are something that not many people run into, but hitting the limit hurts, hard. Kudos to Eliot for taking this on.
Again, it hurts hard not because you reached those limits, the fact that you reached them is indication that your design contain severe problems which you should deal with first, instead of patching the language to allow you continue exploiting and building even more bloat.
- Bert -