[Vm-dev] Sounds baaad sounds

[Igor Stasenko]

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 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.

This code smells. Usually things smell bad because they rot. :)
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."



> Cheers,
>  - Andreas
>

-- 
Best regards,
Igor Stasenko AKA sig.