stops compiling

[Unknown W. Brackets]

That's just bad design.  I thought they still taught basic looping and 
scripting in schools these days.

But, in the end, you'll have to understand that being "a warrior" on the 
internet is not a good thing.  Instead, I much prefer to have pleasant 
working relationships with people.

I understand if you prefer to fight, and to argue.  But I'm just not 
interested in arguing with people like you.  Especially since you, as 
much posturing as you may go through, don't sound like someone I would 
contract work out to.

But, really, I mean no offense by that comment.  I'm sure you're a 
reasonable guy, and just don't like dealing with us "open source types." 
  And that is, of course, your right.

-[Unknown]


> In article <dvtehj$1pj$1 at digitaldaemon.com>, Unknown W. Brackets says...
>> Either way, 16,000 statements in the same scope are an obvious example 
>> of bad coding style ::).
> I invite you to describe your _better_ coding style under aproximately following
> restriction.
> 
> You have to code a script used by a generator that offers you three definition
> facilities: PRE, POST and ITEM and you must implement a sparsely populated
> function f from natural numbers to natural numbers. Where sparsely means at most
> 10,000,000 elements out of 4,000,000,000 possible elements and the values of the
> pairs for the function are given as $(x) and $(y)
> 
> My _bad_ style looks like this:
> 
> <script>
> PRE:
> define uint X;
> define uint Y;
> Y[X] f;
> void init( uint x, uint y){
> f[cast(X)x]=cast(Y)y;
> }
> static this(){
> POST:
> }
> ITEM:
> init($(x)u,$(y)u); 
> </script>
> 
> That are nine lines to understand and maintain.
> 
> In case you will accept this invitation in addition to your coding solution I
> expect a sound argument, why your proposed _better_ coding style will spare a
> significant amount of maintenance man time.
> 
> Otherwise it should be clear who of us is a warrior.
> 
>