On 1 February 2011 18:14, Andreas Raab andreas.raab@gmx.de wrote:
On 2/1/2011 5:50 PM, Igor Stasenko wrote:
On 1 February 2011 16:04, Andreas Raabandreas.raab@gmx.de wrote:
That's really nice design, because you can place all primitive-related part into platform/dialect specific package and it enables you to use same FileSystem API among not just various forks of Squeak, but even among various dialects of smalltalk, without need of hacking/porting core API classes!!!
Yes, that is a very nice approach if the goal is to support different backend primitives. On the other hand, *unless* that is the goal and *unless* there are significant differences in the backend implementation the approach borders on needless complexity.
Hmm.. Are you sure that following is not 'needless complexity'?
ADPCMCodecPlugin, having ZERO methods at its instance side, and only one method at its class side.
ADPCMCodecPlugin class>>translateInDirectory: directory doInlining: inlineFlag "handle a special case code string rather than generated code" "Not currently hooked into the timeStamp mechanism for VMMaker since this would mean replicating code from InterpreterPlugin; waiting for a more elegant solution to appear. In the meantime this means that this plugin will always get regenerated even if the file is uptodate" | cg | self initialize.
cg := self buildCodeGeneratorUpTo: InterpreterPlugin.
cg addMethodsForPrimitives: ADPCMCodec translatedPrimitives. inlineFlag ifTrue:[ "now remove a few which will be inlined but not pruned" cg pruneMethods: #(indexForDeltaFrom:to: nextBits: nextBits:put:)]. self storeString: cg generateCodeStringForPrimitives onFileNamed: (directory fullNameFor: self moduleName, '.c'). ^cg exportedPrimitiveNames asArray
this method alone could spoil someone's day because as it appears that this class serves only as a facade, while all of the behavior lies somewhere else.
So, if that is not an example of 'unnecessary complexity', then what it is? :)
Why do you think I would disagree with your analysis? ;-) ADPCMCodecPlugin is not exactly a shining example of compactness and straightforwardness. But adding another layer surely won't improve on that ;-)
Why bother creating ADPCMCodecPlugin, when code generator can do this by itself by simply looking for all implementors of #translatedPrimitives of all classes in system, and generate necessary primitives out of them. Simple, universal and doing the same, because there are no clear separation between 'what is a primitive' and what is language side code. But if that is not a goal, then why bother, right?
I think that this approach could be applied to sound prims as well, to nicely decouple a front-end API, from low-level backend, implemented either primitively or 'naively' or whatever.
It could, but see above. What would be the point of doing this? It just adds complexity and unless there is tangible benefit I'm against adding needless complexity. I mean, if one indirection is good, two must be better, no? ;-)
I cannot agree. Good design which comes from dependency decoupling and good abstraction layer(s) is not 'unnecessary complexity'. In fact, in far perspective, it works straightly in opposite direction.
I completely agree. But in this case the decoupling already exists. It's the primitive where the decoupling happens. The extra indirection is helpful only if one needs multiple (non-primitive) backend implementations.
but it is already like that , no? if there is no primitive, then it fails and code is interpreted directly instead.
Without that need it's a pointless indirection. For example, would you really consider it better design if we added the same kind of extra indirection for SmallInteger primitives? That's why I'm saying I don't like to add complexity unless there is tangible benefit in return. If there is, then absolutely, go for it. But if there isn't, then let's be careful with additional layers. They tend to get out of hand much too quickly.
This code smells. Usually things smell bad because they rot. :)
Which code specifically? ADPCMCodecPlugin? Agreed for the most part. But then again, I don't think adding another indirection will address that smell particularly well.
And what people usually do with things which rotten? They throw them out. Yeah, there are few, who so passionate that they could overcome the disgust and start digging in rotten pile of cruft in hope to find precious gems. But usually this not happens often, because people having more fun things to do.
Hopefully the above explains better what i meant by saying: "the only means how to maintain this code is either freeze it for ages, or throw it out completely." to which you replied with: "I fail to see how either one follows from the premise."
And I still don't see it :-) You seem to forget the option to simply fix what's broken. That's so obvious that I still don't get why freezing or throwing away would be the only options.
Well, from your words it sounds that i should not fix it. Or should not do it like i proposing. Currently i don't care about eventual complexity increase or not. What i care about is VMMaker consistency.
The problem that i (why i? WE!) need to have guaranteed way to reproduce the VM sources, no matter what base image i using (be it Pharo, Squeak or Cuis or Croquet). In cases when generated VM code almost directly or indirectly or in some nontrivial way depends on code inside an image (which not explicitly declared as part of VM), this is problematic, because obviously nobody could be able to track all these dependencies, because then it requires too much knowledge and magic incarnations to simply build same VM as you built , and therefore when people who know all these shady corners in labyrinth leave our community at some day, then we will be left with an artifact which no one will be able to reproduce sitting at home and running a build script. Then if next time someone will say "my image crashing, how to fix that?", the most probable answer will be "we are not sure" or "we don't know". And after getting such kind of answers, people usually start looking for better tools to use.
My vision is simple: VM-side is VM side. Language side is language side. This is because VM compiled statically and can't change during runtime.. and if not that, then there will be no any issues with it :)
It appears that pharoers incidentally touched stuff which are not supposed to be touched under pain of death. Sure thing they was not aware that thing which they touching contains behavior which goes directly into VM. So, i'd like to not see such incidental refactorings in future. Because people having right to change the language/system in the way they want without fearing that they incidentally will change the most heart of a system - VM. And for that we need a clear separation with BIG red banner: if you cross that line - there is no turning back.. (or something like that ;)
Cheers, - Andreas