On Dec 11, 10:21 am, mdipierro <mdipie...@cs.depaul.edu
> This feature as well as the new Keyed Tables (which do somewhat what
> you say) were proposed, implemented in trunk, and there was an RFC on
> this mailing list. They both made in trunk one month ago. I understand
> you do not like the syntax but you cannot complain about it now that
> it is done.
... I am merely commenting on what I saw in this thread, and raising a
suggestion that google code-review could be more useful than group
threads (and comments / decisions stay with revision history). I
hear that you think group / email threads are "good enough" - maybe
so, but I stand by my suggestion that this thread is evidence that the
code-review process in place on google code would be beneficial beyond
what was in place.
Perhaps you are right - perhaps "Field()" is appropriate here, even
though everything about it's handling is special (all the other field
options, as far as I can tell, do not apply).
I do see this was / is not clear on this thread, and the discussion /
decisions are not part of the repository (a benefit which google code-
review will add).
> I believe the current implementation is much cleaner than the one you
> propose, in fact it was implemented without creating any new API.
Perhaps; no new API either way... but your reply seems as if in
response to an offense... none intended;
> Unfortunately these features are only one month old therefore they are
> not in the book, need more testing and need more documentation.
Denes has documeted the items not documented in this list; the code-
review thing on google code would add a level of documetation too.
> Keyed tables for now only form for some dbs. The functionality will be
> extended as needed by users while keeping the current syntax.
> There is no FNM (?!).
FMN - magic numbers; in CS it is something we graded down for
strongly in our University (of course, this was years ago);
What this refers to is constants used, where a "name" - an abstract,
descriptive form would serve better, and even more strongly where the
same constant was repeatedly used. There are _some_ cases where a
constant is clearer, and surely in Python so much is processed as
But in this case I specifically refer to a string - the SAME string -
where it is used in a multiple of ways, and thus is an example of the
intent of the term I fondly carry with me all these years from
University, "FMN" - that is, something that could be made clearer.
A simple grep for 'id' in gluon/sql.py shows it appears 40 times; of
this, it appears in a line where 'type' is somehow part of the line (a
use of the constant string which I would say is valid, and clear) all
of 7 times. That leaves 33 times where - upon perusing the code -
one is left to "parse" on their own: is this referring to the
definition of the field type? Is this a reference to the field type
in a DB backend descriptor? Is this looking for the field NAMED id?
In short, it is an example of why my professors even thought up the
term FMN - much like:
result = read.port
is not as clear as (say)
result = read.port[USB_CHIP_SELECT]
These really are basics of communicating, I think - the "literature"
> In fact the 'id' type always existed. The 'id'
> field has always been of 'id' type since web2py 1.0 in October 2007.
I understand. That is not what I am talking about. Your code has
'id' as the field type; 'id' as the field name, and possibly other
kinds of references.