kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Thu, Aug 09, 2012 at 09:00:32AM -0500, Dick Hollenbeck wrote:
> If that contract needs to be renegotiated, then lets begin the process of renegotiation,
> rather than starting immediately into a breach of contract.    I for one want the ugliness
> out of the C++ code.

I agree that boundary checking for everything that is usually 'granted'
by the C++ would be a lot of 'spurious' assert/exception throwing.
That's why I've migrated some types (for example layer number and layer
masks) at least to enum in my branch, to get stricter type checking.
Which is exactly the *opposite* languages like python do.

For me this is a classical impedance mismatch case... I see 3 alternatives:
- Trust people to always pass the right stuff to python (right, yeah)
  
- Convive with parameter checking; that's the bread and butter of Eiffel
  and program-by-contract programmers... I find it a little distracting
  (you risk having more parameters checking than actual code!) but
  that's the core of 'defensive programming', at least you gain
  extensive checking for all the exposed interfaces.

- Implement a facade adapter in python, ie an intermediate class which
  checks stuff and then call the 'low level' routines... that's what
  many common lisps and even HP RPL calculators do:P I heard that most
  of the javabeans stuff is for this kind of interfacing, too.
  Of course there's a performance price, and you have to keep updated
  the facade classes, but at least you can optimally abstract for the
  target (a stupid example: instead of getting an int for a layer, get
  a string and look it up before calling the C++ code).

An that's why in distributed system usually is a *bad idea* to expose
directly the internal interface... electronically is the same as putting
out the MCU pins without ESD protection (seen that too many times, many
times redesigned almost only for fix these issues...)

Scripting can't simply be *grafted on* in a robust why IMHO

-- 
Lorenzo Marcantonio
Logos Srl