[Vm-dev] Sounds baaad sounds

[Andreas Raab]

On 2/1/2011 5:50 PM, Igor Stasenko wrote:
> On 1 February 2011 16:04, Andreas Raab<andreas.raab at 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. 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.

Cheers,
   - Andreas