Printable View
There is a question I have always wondered: why the member name of the Type variable can be a keyword, for example:
It would be great if the class could use keywords as property names.Code:Public Type MyType
Type As String
Boolean As Boolean
End Type
Context, those structure members are enclosed by Type/End Type. To refer to them you must write variable.Type and variable.Boolean. (Even inside a With/End With block there at least still is a leading period to distinguish members from keywords I guess it's beyond the limitations of the compiler to handle class procedures with names identical to keywords. As there is no leading variable name it all depends much more on context. Personally I would avoid object names identical to keywords completely regardless of whether or not the compiler accepts it.
Yes, but in many cases we need to use the keyword "Type" as the class property name, and we have to change node.Type to node.NodeType.Quote:
Originally Posted by Peter Swinkels
I'd rather go the opposite way: I'd restrict it even more.
If a word/symbol is a reserved (key)-word, then you can't use it as variable-name, field-name, whatever. Period!
You never need to use a keyword as a property or variable name. You might want to but you never have to and you should not want to either as it can cause confusion and is always easy to come up with a different name that makes sense.
This is so inconvenient on so many levels!Quote:
Originally Posted by Zvoni
The only reason a language has keywords in first place is lexer/parser efficiency and lazyness (less context parsing). For instance TwinBasic and Rubberduck (and any ANTLR based parser) does not limit keywords usage in the same VB6/VBA language parser implementation because they can parse identifiers no matter if these look like keywords -- the parser doesn't care. So the restriction on keywords is artificial becase Microsoft's VB6/VBA parser is ancient.
Think about Type property on ADODB.Stream -- it can be called from VB6 but you cannot have a property on a VB6 class called "Type". Why? The "Type" keyword is right after "Property Get" so the context is clear. I would argue that even method names like [This Method Will Test Important Feature] should be allowed when quoted -- there is no size limit and/ot whitespace limit in typelibs.
This restriction on keywords usage will probably be lifted in TwinBasic and other new variants so sanity will be restored.
cheers,
</wqw>
wqweto,
suit yourself! :-)
Since i don't use any Keywords for my own symbols whatsoever, i'm not really bothered with this restriction or non-restriction.
This even applies to database table- and column-names and anything else.
It always gives me the creeps, when i read an SQL-Statement like
SELECT ItemNo, SUM(SUM) AS SUM FROM table GROUP BY ItemNo
And what do you know: I friend of mine has a commercial software he wrote for MySQL5.X, and we were completely stumped why it wouldn't work on MySQL8
Well, the culprit was: He had a table called "group", which in MySQL5.X was allowed/not a keyword, in MySQL8 it was a keyword.
One of his clients upgraded to MySQL8, and KABOOM!
Will teach him, not escaping table- and column-names..... :-)
I have a friend that never uses keywords but when upgrading to MySQL 8 all his codes exploded because he used a table called BUCKETS which was not a keyword in previous version of MySQL.Quote:
Originally Posted by Zvoni
In MySQL 8 this unfortunate table name was added to keywords list by MySQL developers without consulting with my friend at all and so backwards compatibility was broken as is the case with every major version of a RDBMS, OS and application.
This is the reason why Microsoft and Oracle should stop using lame parsers and allow identitifiers being keywords in each and every possible case without exploding with lame expression errors.
cheers,
</wqw>
I needed to use a keyword, but I couldn't.Quote:
Originally Posted by DataMiser
My SSTab replacement is not fully backward compatible because I was not able to use "Tab" as a property name (as the original does) because it is a reserved keyword in VB6.
Well consider this. i wanted to have a class with Write() and WriteLine() methods. "Write" is a keyword with global scope so I needed a workaround. "WriteLine" was only included in the interface for symmetry, not need.
StdOutSim.cls
RunScriptInterfaces.odlCode:Option Explicit
'
'A partial WScript.StdOut object simulation.
'
'We'll implement the "abstract class" IStdOutSim here:
Implements RunScriptInterfaces.IStdOutSim
Private Sub IStdOutSim_Write(ByVal Text As String)
UIForm.txtOut.SelText = Text
End Sub
Private Sub IStdOutSim_WriteLine(Optional ByVal Text As String = "")
IStdOutSim_Write Text
IStdOutSim_Write vbNewLine
End Sub
The coclass definition is probably redundant and perhaps should even be removed.Code:// Generated .IDL file (by the OLE/COM Object Viewer)
// edited to create type information for an interface class
// "IStdOutSim" for use with the VB6 "Implements" pragma.
[
uuid(87B0BB36-CD32-428F-A7ED-B4F06CB2D5CB),
version(1.0),
helpstring("RunScriptInterfaces Type Library")
]
library RunScriptInterfaces
{
// TLib : // TLib : OLE Automation : {00020430-0000-0000-C000-000000000046}
importlib("stdole2.tlb");
// Forward declare all types defined in this typelib
interface _IStdOutSim;
[
odl,
uuid(247EA0EA-9A84-43E9-A52F-5D1A7BB045F2),
version(1.0),
hidden,
dual,
nonextensible,
oleautomation
]
interface _IStdOutSim : IDispatch {
[id(0x60030000)]
HRESULT WriteLine([in, optional, defaultvalue("")] BSTR Text);
[id(0x60030001)]
HRESULT Write([in] BSTR Text);
};
[
uuid(F2A70052-D436-477D-8E61-4193486AC9E5),
version(1.0),
helpstring("IStdOutSim Interface Class")
]
coclass IStdOutSim {
[default] interface _IStdOutSim;
};
};
Hi dilettante, thank you for your approach. I need to spend some time researching your method.
In addition, I'd like to know whether we can write a general function to dynamically generate odl files and automatically compile it into tlb? Thanks.
I'm not sure how a function would do that.
It might be easier to write a generator tool that accepts some sort of VB-friendly "interface definition" source code and compiles it into ODL or MIDL and then runs midl.exe against it to make the TLB. That source could look like VB but allow keyword names for methods and properties, or even events.
If you want to write such as a tool as a function (why?) I suppose you could. It seems to make more sense as its own EXE though. Even an IDE add-in is sort of pointless, since our problem here is those reserved words in the first place.
But you still need a compiler to translate IDL (ODL or MIDL) to a typelib. I'm not sure this is a wheel worth reinventing. I use the midl.exe from the Windows SDKs. Note that most IDL source needs to include from other .IDL and header (.H) files too. By the time you take everything into account you are almost better off using the Windows SDKs' build environments.
It can get complicated and not much is going to simplify it much without a ton of work. Most people just avoid using reserved words unless there is a big payoff for the effort.
I pretty consistently use hungarian notation for all my variables (intrinsic types, UDTs, & objects), so it's seldom a problem for me. However, theoretically, my vote is with wqweto. It's pure laziness on Microsoft's part that there are any keyword restrictions at all.
Also, when we don't have those restrictions, it forces us to be clear on scope, lifetime, and precedence when using variables ... but, personally, I think that's a good thing.
IMHO, a language should be as flexible as possible, and Eduardo brings up a great point that he couldn't make his control 100% compatible for this very reason.
Hi guys! I already found a solution for Eduardo- to use .tab (compiled the ocx and its working) that perhaps can be used for other specific keywords. Just edit VBA6.DLL, look for the keyword and change the name.Create your OCX file and after that restore the original file if needed. Im still using the modified one and see no problem.
Another option is to use Tab_ and Type_ with underscore as property names in the IDE and then rename these in the compiled type library before shipping to clients.
http://powervb.mvps.org/
There is a Typelib Editor and an add-in along with Matt Curland's book which can automate this task as a kind of post-build step.
cheers,
</wqw>
Great shagratt!Quote:
Originally Posted by shagratt
I tried that method, but the EditTLB program saves the edited file as a TLB file, not an OCX.Quote:
Originally Posted by wqweto
There has to be a way to replace/embed the TLB inside the DLL after this.Quote:
Originally Posted by Eduardo-
cheers,
</wqw>
Yes, sure, I also guess so. But IDK what program is needed.Quote:
Originally Posted by wqweto
Anyway shagratt method worked, I already added the modified file at GitHub.
It keeps the original TabSel property, but it doesn't appear on the property window, and added the Tab property with a redirection to TabSel.