[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    Re: [quanta-devel] Class Variables - no attrAutoCompleteAfter patch
From:       Andrew Lowe <andrew.lowe () manildra ! com ! au>
Date:       2007-02-15 11:28:13
Message-ID: 45D443CD.7010600 () manildra ! com ! au
[Download RAW message or body]

Andras Mantia wrote:

>So the comments. ;-) 
>
>Optimization issues:
>
>+          if (s.find('(') == -1)
>+            qTag->type="variable";
>+          else
>+            qTag->type="function";
>
>This can be optimized because a few lines before there is :
>qTag->setName(s.left(s.find('(')));
>
>Caching the result of s.find('(') makes sense, especially that this is 
>time critical code.
>
>Again, a micro optimization would be to do the next test
>+          if(qTag->type == "variable" && qTag->className.length() != 0)
>
>inside the "if ... else" above. qTag->type can only be "variable" if 
>s.find('(') returns -1, right?
>
>Some optimizations are needed below as well: cache the result 
>of  "tagWholeLineStr.mid(tagWholeLineStr.find('\n')+1,tagWholeLineStr.length())". 
>String operations are usually expensive.
>"tagWholeLineStr.find('\n')" can be cached as well.
>Similar issues a few lines below.
>
>  
>
I will make these changes....

>If the variable is a function argument, maybe we shouldn't put in the 
>userTagsList at all, instead of resetting the className? I'm unsure 
>which version is better.
>
>  
>
You may want to autocomplete function arguments as normal variables ie. 
when you type '$', but you do not want them as class arguments ie. after 
the '->' so I would think we just need to remove the className?

>In the completion code, I don't understand something. You set 
>
>completion.type = type[tagNameList[i]];
>
>But this will be wrong for XML, as in case of XML, type is unitialized. 
>Shouldn't this be moved inside the 
>+    if(completionDTD->family==Script)
>?
>
>  
>
Yes, so it should - which incidently is what I moved from inside the if 
block, when I said I had found a mistake :-)

>This is what I could spot looking at the code, and except  the last 
>issue, the rest is I assume before you are not so familiar with C++ 
>(and KDE) coding practices. 
>  
>
This is true - I am used to PHP which tends to encourage being a bit 
lazy... optimisation is much less important then getting the job done 
quickly, and being able to quickly make changes - as scripted languages 
over http tend to be less time critical, and at work we constantly need 
to make updates to our code, and very quickly...
I also was a bit wary about how much I changed - tried to keep it 
together, and not add to many new variables... but you have reminded me 
about optimisation and time critical requirements...

>I didn't test it yet, but I will do after you comment on the last part. 
>If you provide an updated patch with the optimizations, that is even 
>better.:-)
>  
>
I will look at it in the morning - it is getting late over here... and 
you should have an updated patch tomorrow...

Thanks for the guidance.

-- 
Andrew Lowe
    System Administrator & Programmer
        Information Technology
            Manildra Group

Email:   andrew.lowe@manildra.com.au
Phone:   02 4423 8270
Mobile:  04 1323 8270
Fax:     02 4421 7760 

_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel
[prev in list] [next in list] [prev in thread] [next in thread]