Le 14/03/2022 à 17:34, jr a écrit :
 > hi,
 >
 > Bruno Cabasson <bru### [at] yahoofr> wrote:
 >> Hi folks!
 >>
 >> Please find hereafter new versions of "primitives.inc" and
 >> "collections.in" with unit-testing code.
 >>
 >> Working on unit-testing "oocore.inc", the core Object Oriented features.
 >> Then will come "objects.inc" and its unit-testing file(s).
 >
 > have had a look around, some nice ideas there, genuinely looking 
forward to
 > seeing where, application-wise, your efforts will lead.  while the 
following
 > will probably read like "critique", it's not really, just highlighting
 > (potential) issues, and yes, adding a "gripe" or two .
 >
 > names.  collections.inc:234:"// Could not use 'slice' as it is a SDL 
keyword".
 > so why not 'Slice' (not that I'm advocating uppercase use :-)) or 
'_slice'?  the
 > problem, imo, is not the keyword per se, but your use of names like 
'get()' for
 > "globally visible"s, ie no "namespacing".  the "obvious" choice would 
be 'oo'
 > followed by underscore or camelcase.  (macro names used unadorned 
include:
 > check, exec, exists, extend, get, in, list, map, next.  sure, not 
keywords, but
 > common perhaps?)

===> I see these macro names as if they were part of the native 
language. Thus, I try to avoid CamelCasing or use underscores as prefix 
of suffix.

 >
 > if I understand the code correctly, in 'primitives.inc' you use the 'rgb'
 > keyword to coerce values to 3-vector format?  would '<1,1,1>*value' 
not do the
 > same, "cleaner"?
 >
 > extend() - not sure how far you will be able to .. bend SDL , but 
think that
 > an important macro like extend should be "general".  clipka's advice 
wrt arrays
 > was (paraphrasing) "if you know the #elements in advance, declare the 
array
 > sized"; however, if I were to:
 >    #declare A = array [2] {"a","b"};
 >    #declare B = array [2] {"c","d"};
 >    extend(A,B)
 > I'd get: "Parse Error: Array subscript out of range".
 >

===> You are correct. The use of some PROOF features may (and will) 
imply some restrictions. But that's highly secondary for me. In this 
particular case, I don't know if Sdl can detect if the array is of fixed 
sized. Please, enlighten me.


 > gripe(s): why does yr editor not always place whitespace between 
keyword and
 > brace?

===> Please, precise your mind.

personally also not a friend of long lines, particularly when concluded
 > by C++ style comment(s).

===> I agree that some lines are a bit long. Beautifying detail for now.

  including another include (colours) for just white +
 > yellow?  (also makes the versioning more "dependent")  tja,

===> Why not? Including a *small* file is not a problem. Did you never 
#include'ed & C/C++ file or import'ing a python module for just one 
symbol? Performance is not in my scope yet, and not significant for such 
a small file as colors.inc. Besides, #version'ing has ALWAYS been an 
issue and been part of our coding process.

    and then there's the
 > unit test output..   without any documentation for yr project, the 
results of
 > unit testing can only be of interest if the output _tells_ what one 
is looking
 > at, and states (consistently) 'fail' or 'pass', or such.  (time _is_ 
precious)
 >

===> PROOF is in an early state of POC, nothing more at the moment. Sdl 
does not ship with an UT engine, as other languages do (eg pyUnit for 
Python). So I do what Sdl currently allows me to do quite easily. My 
tests are abolutely not ment to be exhaustive. However, they are a 
minimum guarantee for myself and the code to be used for the next steps 
of the POC, even though they just output text. The output shows the 
functionning of my macros. It is no time for developping a UT engine 
prior to PROOF, in particular in this phase. Any contributor is 
welcome... It is also no time for documenting. Way too early. PROOF 
could be a conceptual flop... I try to comment (almost) everything so 
that the reader makes a global idea of things I write. I think I added 
quite a lot of explanations for where I am now.


 > anyway, as I said, curious + interested to see how it will all develop.
 >
 >
 > regards, jr.
 >

Hi. Sorry for the delay. I was on vacation last week without great 
possibility for POVing.

Your remarks are welcome and I'll take them into account in a next 
version. I also look forward for other people to comment and suggest.


New package including oocore.inc with (pseudo?)unit-tesing coming soon.


Regards

     Bruno



-- 
L'absence de virus dans ce courrier électronique a été vérifiée par le 
logiciel antivirus Avast.
https://www.avast.com/antivirus



-- 
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus

Post a reply to this message