On 2/16/20 5:00 AM, Jason H wrote:
I'm here watching Ulf's QtWS19 QML talk and had a thought...
I might be dumb or crazy (either are equally likely) but, the other day I added a
property called 'data' and completely broke my application. It was to store data I
received. However QML also declares a property 'data' which is essential to Qt. But I
never got an error or warning. So my suggestion is to have some warning (or error?) like
"declared property 'data' shadows an existing property"
I think some talk of naming an essential-to-QML property as generically as
'data' is also worth a discussion. Naming it 'data' doesn't really describe
what it is for, which is holding the children, all the children. The problem
with that, is as it currently stands, the property 'children' is used to store
only visual children, so I would suggest to rename that 'visualChildren', or
'childItems'. Next for the non-visual children, aka 'resources' (equally poorly
named, because Qt has a 'resource' system), they should be in 'childObjects' or
'nonvisualChildren'. (But definitely not 'invisibleChildren', because is that
visible=false or opacity==0 property thing?)
Now that it has been about a day and you can probably smile about it I
can pick at the scab. <Grin>
What were you doing declaring a variable named "data"? You know better
my friend. <Very Big Grin>
I understand what you are asking for, you want QtCreator to be able to
do something along the lines of what it does for C++ code. It amazes me
how the Great Bad Old Days keep repeating themselves. Creator is now
caught up to, perhaps slightly ahead of the Rational Systems Instant-C
product circa 1984.
http://www.softwarepreservation.org/projects/interactive_c/bib/Vose-1984.pdf
http://vetusware.com/download/INSTANT-C%20VER%202.00/?id=10724
The content of the Byte article in the PDF actually had it wrong. The
big benefit wasn't to students. It would do much like QtCreator does for
C++ today. "Interpret/JIT" your code while you typed and let you know
you were using a class member variable which wasn't declared or a
method/function which didn't have a prototype, etc. It's been a long
time so I don't remember all it could do on an EGA monitor. In the Great
Bad Old Days we would pay $300-$500 for an editor that could do
something like that. Admittedly I never understood why anyone paid that
for Brief https://en.wikipedia.org/wiki/Brief_(text_editor) yet I paid
it for SlickEdit which was just another Brief. https://www.slickedit.com/
What can you really expect from something which is insecure and not type
safe? The insecure thing happens from at least 2 points of entry. The
first is a programmer cannot control the life of a variable. As others
have mentioned in here even assigning a new value to the variable one
uses to receive a password doesn't erase the password from memory. The
second comes from the JavaScript code being bundled into the binary you
ship without so much as a Base26/64 mangling. I actually spoke in the
past month to a non-client that was coding trade-secret algorithms in
the OpenSource Qt version using JavaScript who was completely unaware of
this. To get their algorithms you don't have to reverse engineer the
code, just open the binary in a text editor, read the JavaScript, type
it in C++ and compile it. Your version should even run faster.
In the Great Bad Old Days, prior to namespaces, we had to rely on warts.
Here is a snippet of a program from the very first book I wrote for a
publisher.
int attach_inv_database( DBFoxPro& inv_dbf, int o_mode)
{
char *dbf_name = "INV.DBF";
char *idx_name = "INV.CDX";
int x;
int c_mode;
char error_str [80];
x = inv_dbf.UseTable( dbf_name, o_mode);
if ( x != DBSUCCESS)
{
inv_dbf.CloseAll();
DBFIELD inv_flds [] = {
{ "ITEMNUM", 'C', 25, 0},
{ "DESC", 'C', 60, 0},
{ "ONHAND", 'N', 8, 2},
{ "OUNITM", 'C', 7, 0},
{ "SCHED", 'N', 8, 2},
{ "SDATE", 'D', 8, 0},
{ "SUNITM", 'C', 7, 0},
{ "", ' ', 0, 0}};
c_mode = DB_READWRITE | DB_EXCLUSIVE | DB_FLUSHED |
DB_AUTOLOCKS;
x = inv_dbf.CreateTable( dbf_name,
inv_flds,
c_mode);
if ( x != DBSUCCESS)
{
sprintf( error_str, "Error %d creating table", x);
ls_error_msg( error_str);
return x;
}
The code is using the Greenleaf Database Library and it is from back in
that era. Greenleaf had a lot of libraries so their warts were really
good. They had test programs which used all of their libraries so one
could be certain you wouldn't suffer collision. Everything for the
database library was warted with "DB". Every #define and every global
variable had the wart. One just had to avoid using DB as a personal wart.
Some shops today still use the class member variable wart of "m_" but
there was a large cultural rebellion against warts. In large part it was
because Microsoft took it too far.
https://docs.microsoft.com/en-us/windows/win32/stg/coding-style-conventions
=====
Prefix combination Description
pszMyString A pointer to a string.
m_pszMyString A pointer to a string that is a data member of a class.
=====
For the strings it wasn't so bad, but they also had i for Integer, l for
long, n for Short int, etc. When the data type had to increase in size,
globally changing the name was something often not done.
I can concur with you though. Every property created and used by the
library itself, given the lack of control a developer has in the
QML/JavaScript world, should be warted with "Q_" to avoid collisions.
The fact the "_" tends to violate most shop naming standards helps
ensure it will avoid collision.
History will once again repeat itself.
http://www.c4learn.com/c-programming/c-variable-nameing-rules/
=====
Do not use underscore as first character to avoid confusion between
System Variable & user defined variables because many system variables
starts with undescore
=====
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
_______________________________________________
Interest mailing list
[email protected]
https://lists.qt-project.org/listinfo/interest
