clipka a écrit :
> Am 05.04.2010 21:03, schrieb Le_Forgeron:
> 
>>> would have the benefit of not adding any new keywords ;-).
>>
>> Adding a keyword is not difficult, and would avoid confusion of the
>> final users. (if you use the same keyword all over, we will end up with:
>> "a rose is a rose is a rose is a rose..." which are nice but painful to
>> understand)
> 
> The policy is to avoid introducing more keywords where sensible, to
> avoid unnecessarily breaking legacy scenes that happen to use the same
> word for a variable.

Nah, wrong solution to a wrong issue.
Current editors made it easy to refactor a variable.
Moreover, if the #version is correct in the scene, the new keyword
should not trigger any issue at all (but I'm a bigger fan of: no
backward, break everything if it can be more simple to explain &
understand; even if I somehow appreciate backward compatibility).

We might need some java-coding-policy (about Capitalising/small char) to
avoid such sillyness in the futur... How do you want to extend the SDL
if you are limited to existing keywords... twisting the syntax is a very
bad idea, IMHO.
In fact, the lack of keywords is one big reason for failure of poly in
popularity: counting the coefficients is painfull when you have 34 of
them used by position. entering basic equation is a challenge, a write
only challenge as trying to read it back is even more complex, do not
even think about tunning it.

4x^4+3xy²-z = 0 looks simple... but the resulting array of numbers is a
hell to edit!

> 
>> repeat is currently used in warp, so it might be best to avoid it.
> 
> Repeat is currently used in warp for pretty much the same purpose as
> proposed (at least for the 1D repeat): Specifying a vector and distance
> for repetition (though it has some limitations with warp). So why call
> the same thing differently?
> 
>> And it should be a name, which "repeat" is not.
> 
> Is "translate" or "rotate" a name?

they are not objects, but update of objects.
Don't push it too far on bad faith, please.

> 
>> I'm not sure the transformation from 3D filling to cubic would be
>> obvious (and you might need holes on some places, and it might be better
>> to code it once for each filling rather than applying specific
>> transforms all the time)
> 
> I guess macros should be enough to fill that gap.

I believe it would be quicker and more effective to cover the patterns
in the C++ code rather than with a transform.

I'm still wondering about the number of actual space filling pattern (3
so far in 3D: 1 with cube, 2 with spheres, and 2 in 2D: square, hexagon)
Any others you or others know of ?

Post a reply to this message